Re: [PATCH net-next] fq_codel: add memory limitation per queue

On Mon, 2016-05-09 at 21:34 -0700, Cong Wang wrote:

On Mon, May 9, 2016 at 7:26 AM, Eric Dumazet [off-list ref] wrote:

quoted

On Sun, 2016-05-08 at 22:07 -0700, Cong Wang wrote:

quoted

On Sun, May 8, 2016 at 9:31 PM, Eric Dumazet [off-list ref] wrote:

quoted

On Sun, 2016-05-08 at 21:14 -0700, Cong Wang wrote:

quoted

So when the packet is dropped due to memory over limit, should
we return failure for this case? Or I miss anything?

Same behavior than before.

If we dropped some packets of this flow, we return NET_XMIT_CN

I think for the limited memory case, the upper layer is supposed
to stop sending more packets when hitting the limit.

They doe. NET_XMIT_CN for example aborts IP fragmentation.

TCP flows will also instantly react.

But not for the NET_XMIT_SUCCESS case:

        return ret == idx ? NET_XMIT_CN : NET_XMIT_SUCCESS;

I believe you missed whole point of FQ (SFQ, FQ_CODEL, FQ, ...)

If we dropped a packet of another flow because this other flow is an
elephant, why should we notify the mouse that we shot an elephant ?

We return NET_XMIT_SUCCESS because we properly queued this packet for
this flow. This is absolutely right.

If you do not like fq, just use pfifo, and yes you'll kill the mice.