A small fix for if_em.c, if_igb.c, if_ixgbe.c

[John Baldwin]

On Friday, December 13, 2013 4:51:18 pm Adrian Chadd wrote:
> On 13 December 2013 10:26, John Baldwin <jhb at freebsd.org> wrote:
> > On Monday, December 09, 2013 2:37:08 pm Adrian Chadd wrote:
> >> Jack / John - thoughts?
> >
> > Note that if_start has always worked the way if_transmit would work with the
> > err = 0 change.  All the other drivers in the tree are already giving you an
> > error if an earlier packet in the IFQ fails to transmit, and it's been that
> > way for decades.  If you decide to make if_transmit precise (only return an
> > error if the specific packet fails), the corresponding change for if_start()
> > drivers would be to never return an error ever.
> 
> Right. If we want some kind of sane network behaviour moving forward
> we .. well, we have to define it as being sane. :-)
> 
> IMHO if_start()'s API should've been:
> 
> * queue something to the ifnet queue - fail it we can't queue it
> * call if_start() to start trying to transmit something - a failure is
> not that the queued frame failed, but the driver is unable to dequeue
> frames.
> 
> Anyone using if_start() failing as "the frame i just queued failed to
> transmit" is broken and well, we should just replace it with
> if_transmit().

Hmm,  I was a bit wrong.  Driver if_start routines return void, so they
only failed if the IFQ filled up completely.  In that case, I think it is
fine to move forward with what you want (only return an error for failures
involving the packet passed to if_transmit), but I don't think we should 
hange if_transmit drivers to just always return 0.

-- 
John Baldwin