On Wed, 2016-06-15 at 09:34 -0700, Venkatesh Srinivas wrote: > On Wed, Jun 15, 2016 at 6:37 AM, Paolo Abeni <pab...@redhat.com> > wrote: > > > > Currently the function ixgbe_poll() returns 0 when it clean > > completely > > the rx rings, but this foul budget accounting in core code. > > Fix this returning the actual work done, capped to weight - 1, > > since > > the core doesn't allow to return the full budget when the driver > > modifies > > the napi status > > > > Signed-off-by: Paolo Abeni <pab...@redhat.com> > > --- > > drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c > > b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c > > index 088c47c..8bebd86 100644 > > --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c > > +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c > > @@ -2887,7 +2887,7 @@ int ixgbe_poll(struct napi_struct *napi, int > > budget) > > if (!test_bit(__IXGBE_DOWN, &adapter->state)) > > ixgbe_irq_enable_queues(adapter, BIT_ULL(q_vector- > > >v_idx)); > > > > - return 0; > > + return min(work_done, budget - 1); > > } > > > > /** > Reviewed-by: Venkatesh Srinivas <venkate...@google.com> > > The same bit of code appears in fm10k and i40e/i40evf. ixgb appears > to > correctly return work_done. > > ixgbe_poll also appears to return an (minor) incorrect work_done in > another case, BTW. It divides its > budget between Rx rings associated with a vector. If any ring exceeds > its share of the budget, ixgbe_poll > claims to have consumed the full budget, even if a full budget of > frames was not received in a single > pass. > > -- vs;
For the record, I couldn't find any documentation on this in Documentatino/networking, or as a function header. Where would be the best place to document the expectations of the napi core? I'd like to submit a patch so that future it will be easier to determine what a new driver should do (without just blindly copying from other drivers as has caused these so far). Thanks, Jake
