[Cake] NET_XMIT_CN question

[Kevin Darbyshire-Bryant]

Eric Dumazet very kindly answered a few of my questions regarding XMIT_CN.

I think the cake 'NET_XMIT_CN' optimisation has been prematurely ripped out.

Eric's helpful comments:
"
    If a packet scheduler returns NET_XMIT_CN , caller know a packet was
    dropped.
   
    If a packet scheduler returns NET_XMIT_SUCCESS , caller does not know
    a(nother) packet was dropped.
   
    Look for example in htb this part :
   
        } else if ((ret = qdisc_enqueue(skb, cl->un.leaf.q)) !=
    NET_XMIT_SUCCESS) {
             ....
            return ret;
       } else {
           ....
      }
   
    sch->q.qlen++;  // HERE : this part wont be run if NET_XMIT_CN was
    returned.
   
    A packet scheduler returns NET_XMIT_CN when it wants to tell the upper
    stack (like TCP) that it is worthless trying to push more packets for
    this flow, as it is (self) inflicting losses.
   
    Basically it is a (best effort) signal/hint to backoff.
   
    IP fragmentation layer for example aborts its attempt to send
    following fragments.
"

Kevin



On 27/11/15 15:44, Kevin Darbyshire-Bryant wrote:
>
> On 27/11/15 15:16, Dave Taht wrote:
>> We decreased the size of the queue, regardless of what flow we dropped
>> from... so why do we not need to decrease the queue size when using
>> NET_XMIT_CN? Where is that done by the caller? I have grepped and
>> googled...
>>
>> As best as I recall the semantics of NET_XMIT_CN changed over time, it used to
>> only work on enqueue on a tail drop queue, where it would push back on
>> the stack to not, actually, drop the packet, but to halve the window
>> and requeue.
>>
>> Staring at the code now, I don't see how it could be right... here OR
>> in the existing fq_codel code in the mainline.
>>
>>         /* Return Congestion Notification only if we dropped a packet
>>          * from this flow.
>>          */
>>         if (fq_codel_drop(sch) == idx)
>>                 return NET_XMIT_CN;
>>
>>         /* As we dropped a packet, better let upper stack know this */
>>         qdisc_tree_decrease_qlen(sch, 1);
>>         return NET_XMIT_SUCCESS;
>>
>>
>> (I am not sure NET_XMIT_CN works right when there is a hash collision,
>> for example, although the updated doc does seem to indicate that,
>>
>> ... still, then, where does (an equivalent for)
>> qdisc_tree_decrease_qlen kick in?)
>>
>> So I ripped it out. Otherwise... the code does look correct, now that
>> I've reviewed it further.
>> But does putting it back in have any measurable effect?
> I've no realistic way of testing & finding out.  I'd say that if that
> bit of code ever gets executed then things are in an unfortunate place
> already, however if there's a way of telling a 'very active talker' (and
> they must be 'cos they've just queued a packet *and* cake_drop() has
> chosen them as having the biggest b->backlogs[i] - and that may help
> answer one of your todo items as well) to back off, then we should take it.
>
> Spaghetti monster knows what *actually* happens further up the stack :-)
>
>> ...
>>
>> Also I note there was a bunch of commits to sch_fq_codel mainline since july,
>> notably this one.
>>
>> c0afd9ce4d6a646fb6433536f95a418bb348fab1
>>
>>
>> Dave Täht
>> Let's go make home routers and wifi faster! With better software!
>> https://www.gofundme.com/savewifi
>>
>
>
>
> _______________________________________________
> Cake mailing list
> Cake at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4816 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.bufferbloat.net/pipermail/cake/attachments/20151217/284cb140/attachment-0002.bin>