Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 5 Dec 2013 22:05:16 +0100
From:      Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
To:        Adrian Chadd <adrian@freebsd.org>
Cc:        Yong-Hyeon Pyun <pyunyh@gmail.com>, Jack F Vogel <jfv@freebsd.org>, "freebsd-net@freebsd.org list" <freebsd-net@freebsd.org>
Subject:   Re: A small fix for if_em.c, if_igb.c, if_ixgbe.c
Message-ID:  <B89B1E2D-BAF0-4815-B3AB-EB226F4F76DE@lurchi.franken.de>
In-Reply-To: <CAJ-Vmo=kfoPMYjZ0WAtqmoJMz1utXH50SW9N92RA83EMUzY7WA@mail.gmail.com>
References:  <521B9C2A-EECC-4412-9F68-2235320EF324@lurchi.franken.de> <20131202022338.GA3500@michelle.cdnetworks.com> <B9593E83-E687-49E9-ABDC-B2DD615180E9@lurchi.franken.de> <20131203021658.GC2981@michelle.cdnetworks.com> <CAJ-Vmo=kfoPMYjZ0WAtqmoJMz1utXH50SW9N92RA83EMUzY7WA@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Dec 5, 2013, at 7:29 PM, Adrian Chadd <adrian@freebsd.org> wrote:

> Hi,
> 
> Yes. Looking at the ixgbe code, ixgbe_mq_start_locked() returns an
> error from ixgbe_xmit() but if it fails, it puts the buffer back. But
> it's already successfully queued a frame to the driver, so in this
> instance it shouldn't return the error from ixgbe_mq_start_locked().
> 
> The same deal in if_em.c and igb.c
> 
> Now, drbr_putback() used to fail and now it doesn't, as you've said.
> So we should change the xxx_mq_start_locked() to set err=0 if we go
> via the drbr_putback() routine, as it hasn't actually failed to
> transmit.
> 
> Now the very dirty thing is this - the error from xxx_transmit() is
> for the mbuf being queued at the end; but xxx_mq_start_locked()
> failures are for transmitting from the front. If there's only packet
> in the queue and that fails then they're the same thing and returning
> the error from xxx_mq_start_locked() matches the current mbuf being
> queued. But otherwise, they're referring to totally different packets.
> For TCP this may hurt; the TCP stack treats ENOBUFS a certain way and
> kicks off a timer to schedule a retransmit. I don't think we can fix
> _this_ right now.
Just to be clear: This would mean that xxx_transmit() would return
an error even if the packet provided in the call xxx_transmit() is
enqueued and not dropped?
This would also be problem with the current SCTP stack.

Best regards
Michael
> 
> So Michael - can you redo your patch to set err=0 if drbr_putback() is
> called, and retest?
> 
> Thanks!
> 
> 
> 
> 
> -adrian
> 




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B89B1E2D-BAF0-4815-B3AB-EB226F4F76DE>