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

Adrian Chadd adrian at freebsd.org
Thu Dec 5 23:10:31 UTC 2013


On 5 December 2013 14:37, John-Mark Gurney <jmg at funkthat.com> wrote:
> Adrian Chadd wrote this message on Thu, Dec 05, 2013 at 14:01 -0800:
>> On 5 December 2013 13:05, Michael Tuexen
>> <Michael.Tuexen at lurchi.franken.de> wrote:
>>
>> > 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.
>>
>> I think it'll return an error only if:
>>
>> * it queued the frame to the tail of the drbd;
>> * it then tried to transmit a frame from the head of the drbd;
>> * it failed to transmit the first frame in the drbd and it couldn't
>> put it back into the queue for whatever reason.
>>
>> So I think it should be "ok enough" for both TCP and SCTP.
>
> IMO it should only return an error if the specific frame failed to be
> sent or queued.  If you cannot determine at return time if the frame
> failed to be transmitted/queued, then it should return success.

For the long term solution, I agree.

> In the above case, if there were other frames queued ahead, and the
> first one failed, then it sounds like the frame may eventually be sent
> and we will end up sending a duplicate frame.

Right. We should also fix this properly.

I think the right thing, long term, is something like this;

* xxx_mq_start_locked() returns whether the head frame was transmitted or not;
* the if_transmit() entry point(s) return whether the given frame was
queued to the software queue or not;
* the if_transmit() entry point(s) ignore the return value of
xxx_mq_start_locked(), as the stack _should_ handle the case of a
frame handed to the driver but dropped.

So, I'd like to get Michael to first test fixing up
xxx_mq_start_locked() to only return an error if it failed to transmit
a frame and the frame was dropped. Then, once we get feedback from
that, I was going to propose that we also do what Michael initially
did - and that's ignore the error from calling xxx_mq_start_locked().
Followed, hopefully, with some comments explaining how this all holds
together.

How's that sound?



-adrian


More information about the freebsd-net mailing list