On Mon, 2016-05-09 at 21:34 -0700, Cong Wang wrote: > On Mon, May 9, 2016 at 7:26 AM, Eric Dumazet <eric.duma...@gmail.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.duma...@gmail.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.
