On Mar 29, 2005, at 5:50 AM, J Chapman Flack wrote:

>> On Mar 28, 2005, at 7:04 PM, Christos Zoulas wrote:
>>
>>> You are not dropping packets. You are returning ENOBUFS to the
>>> application, and you are giving it a chance to retry.
>>>
>
> and Jason Thorpe replied:
>
>> How does the return value affect the app's chance to retry?  It can
>> just as well retry if you return 0.
>>
>
> I don't have much else to say in this thread, but here I think  
> Christos
> has a point well taken: isn't it useful to preserve a distinction  
> between
>
> a _dropped_ packet, that is, a packet _you think you've sent_ but  
> it fell
> on the floor somewhere, without your knowledge unless/until the  
> protocol
> you're using eventually discovers that the recipient hasn't seen it,
>
> and a packet _you know you've not sent_ because the system call at  
> the point
> of sending tells you "didn't send it, hit me again" ?

Right, so if the distinction is useful, then ENOBUFS is the  
appropriate return code.  This is what our kernel currently does, and  
seems specifically allowed by SUSv3.  It also seems as though other  
OSs have the same behavior we do, so we're not alone in this regard.

So, seems like the status quo is just fine.  Why are we all  
continuing to argue about it?  Can we just kill this thread now please?

>
> Seems to me Christos is on the right track in not considering those  
> two
> cases identical, and in preferring the term _dropped packet_ for  
> the first
> case.
>
> -Chap
>

-- thorpej