On Mon, May 9, 2016 at 9:45 PM, Eric Dumazet <eric.duma...@gmail.com> wrote: > 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. >
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?
