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

[Yonghyeon PYUN]

On Mon, Dec 02, 2013 at 10:48:07PM +0100, Michael Tuexen wrote:
> On Dec 2, 2013, at 3:23 AM, Yonghyeon PYUN <pyunyh at gmail.com> wrote:
> 
> > On Fri, Nov 29, 2013 at 06:24:12PM +0100, Michael Tuexen wrote:
> >> Dear all,
> >> 
> >> ifnet(9) says regarding if_transmit():
> >> 
> >> Transmit a packet on an interface or queue it if the interface is
> >> in use.  This function will return ENOBUFS if the devices software
> >> and hardware queues are both full.
> >> 
> >> The drivers for em, igb and ixgbe might also return an error even
> >> in the case the packet was enqueued. The attached patches fix this
> >> issue.
> > 
> > How do you know the packet is successfully enqueued but driver
> > returns an error?  Do non-buf-ring-aware drivers also show the same
> When debugging the issue, I saw the packet on the wire but the if_transmit()
> returning ENOBUFS.
> > behavior?
> I don't know. I saw this issue with the igb driver.

I see.

> > 
> >> 
> >> Any comments?
> > 
> > I'm afraid the patch you posted ignores any errors(i.e.
> > m_defrag(9), bus_dma(9) etc) happened during TX processing.
> Correct. I want to make sure that if ENOBUFS is returned, the
> packet hasn't made it on the wire. The other errors can occur
> for the packet provided to if_transmit() or due to packet
> processing of other packets. Am I missing something?
> 

No.  It seems the only return code buf-ring-aware drivers can
return is ENOBUFS since queuing is done in the driver.

> Best regards
> Michael
> > 
> >> 
> >> Jack: What do you think? Would you prefer to commit the fix if
> >> you think it is acceptable?
> >> 
> >> Best regards
> >> Michael
> > 
>