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

[Michael Tuexen]

On Dec 5, 2013, at 11:01 PM, Adrian Chadd <adrian at freebsd.org> wrote:

> 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.
No it isn't. The transport layer calls ip_output() (or the v6 variant),
and it needs to know if the packet provided will not be put on the wire.
If it knows for sure that the provided packet was dropped by the local
stack it can do some special treatment. In all other cases, the packet
may or may not make it to the peer and the transport layer will take
care, but can't optimize.

If the above describes what I get from ip_output(), I can only ignore
it, since it doesn't help.

Which layer can make use of the above information?
> 
> Give it a go and let me know how it goes.
The patch in the other mail fixes the problem and improves the
driver.
> 
> It's an interesting architectural problem to completely solve.
Yes, it is. I think setting err=0 makes sense.
However, the information returned by xxx_transmit() as described
above seems useless for me. This is an architectural point as
you said and I'm interested in knowing which consumer of the
return code of xxx_transmit() can make use of it.

Best regards
Michael
> 
> 
> -adrian
>