ip_output()/if_output() behaviour

[Julian Elischer]

On 11/29/13, 10:06 PM, Michael Tuexen wrote:
> On Nov 29, 2013, at 12:44 PM, Julian Elischer <julian at freebsd.org> wrote:
>
>> On 11/29/13, 5:42 PM, Michael Tuexen wrote:
>>> On Nov 29, 2013, at 3:54 AM, Adrian Chadd <adrian at freebsd.org> wrote:
>>>
>>>> On 28 November 2013 12:35, Michael Tuexen
>>>> <Michael.Tuexen at lurchi.franken.de> wrote:
>>>>> Dear all,
>>>>>
>>>>> I'm investigating a problem and need to understand the behaviour
>>>>> of ip_output(). Is it correct that if ip_output() returns an
>>>>> non-zero error, the corresponding packet was never sent?
>>>>> In the SCTP stack we assume this, but it seems that at least
>>>>> the em and the igb driver might return an error from
>>>>> igb_mq_start_locked(), for example, but have accepted the packet.
>>>> Which error(s) ?
>>> ENOBUFS, but does it matter? What is the correct reaction to
>>> ip_output() returning an error? The SCTP stack assumes that the
>>> packet was not put on the wire. With the current version of the
>>> igb driver we are wrong. igb_mq_start() might return an error,
>>> even if the packets was enqueued successfully (in case
>>> igb_mq_start_locked() fails).
>>>
>>> But the SCTP stacks assumes in general that if ip_output() returns
>>> an error, the packet didn't make it out.
>>  From my memory it's always been the case that you really have little
>> idea if the packet makes it out onto the wire or not.
>> In the past it's been the case that an error indicates that it probably DIDN'T make it out, but
>> the converse is not true.. NO error is not an indication of success.
>> I'm surprised that you could get an error when it was broadcast however.. that is counter
>> to the last 30 years of behaviour.
> ifnet(9) says:
>
>             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.  ...
>
> So I guess returning ENOBUFS when the packet was queued is wrong...
I think it is.

ENOBUFS means "I couldn't proceed due to no buffers"
not "I used up the last one on this operation".