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

On Mon, May 9, 2016 at 9:45 PM, Eric Dumazet [off-list ref] wrote:

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

quoted

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.

Sure, but we are talking about memory constraint case, aren't we?

If the whole system are suffering from memory pressure, the whole
qdisc should be halted?