[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1462855514.23934.51.camel@edumazet-glaptop3.roam.corp.google.com>
Date: Mon, 09 May 2016 21:45:14 -0700
From: Eric Dumazet <eric.dumazet@...il.com>
To: Cong Wang <xiyou.wangcong@...il.com>
Cc: David Miller <davem@...emloft.net>,
Jesper Dangaard Brouer <brouer@...hat.com>,
Dave Täht <dave.taht@...il.com>,
netdev <netdev@...r.kernel.org>, moeller0 <moeller0@....de>
Subject: 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 <eric.dumazet@...il.com> wrote:
> > On Sun, 2016-05-08 at 22:07 -0700, Cong Wang wrote:
> >> On Sun, May 8, 2016 at 9:31 PM, Eric Dumazet <eric.dumazet@...il.com> wrote:
> >> > On Sun, 2016-05-08 at 21:14 -0700, Cong Wang wrote:
> >> >
> >> >> 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.
Powered by blists - more mailing lists