On Mon, 2016-05-09 at 21:57 -0700, Cong Wang wrote:
> 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?
Please read the patch again.
I added a mem control, exactly to control memory u
On Mon, May 9, 2016 at 9:45 PM, Eric Dumazet wrote:
> On Mon, 2016-05-09 at 21:34 -0700, Cong Wang wrote:
>> On Mon, May 9, 2016 at 7:26 AM, Eric Dumazet wrote:
>> > On Sun, 2016-05-08 at 22:07 -0700, Cong Wang wrote:
>> >> On Sun, May 8, 2016 at 9:31 PM, Eric Dumazet
>> >> wrote:
>> >> > On Su
On Mon, 2016-05-09 at 21:34 -0700, Cong Wang wrote:
> On Mon, May 9, 2016 at 7:26 AM, Eric Dumazet wrote:
> > On Sun, 2016-05-08 at 22:07 -0700, Cong Wang wrote:
> >> On Sun, May 8, 2016 at 9:31 PM, Eric Dumazet
> >> wrote:
> >> > On Sun, 2016-05-08 at 21:14 -0700, Cong Wang wrote:
> >> >
> >> >
On Mon, May 9, 2016 at 7:26 AM, Eric Dumazet wrote:
> On Sun, 2016-05-08 at 22:07 -0700, Cong Wang wrote:
>> On Sun, May 8, 2016 at 9:31 PM, Eric Dumazet 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
>> >>
On Sun, 2016-05-08 at 22:07 -0700, Cong Wang wrote:
> On Sun, May 8, 2016 at 9:31 PM, Eric Dumazet 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?
> >
>
On Sun, May 8, 2016 at 9:31 PM, Eric Dumazet 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 thi
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
On Fri, May 6, 2016 at 8:55 AM, Eric Dumazet wrote:
> @@ -193,6 +199,7 @@ static int fq_codel_enqueue(struct sk_buff *skb, struct
> Qdisc *sch)
> unsigned int idx, prev_backlog, prev_qlen;
> struct fq_codel_flow *flow;
> int uninitialized_var(ret);
> + bool memory_li
From: Eric Dumazet
Date: Fri, 06 May 2016 08:55:12 -0700
> From: Eric Dumazet
>
> On small embedded routers, one wants to control maximal amount of
> memory used by fq_codel, instead of controlling number of packets or
> bytes, since GRO/TSO make these not practical.
>
> Assuming skb->truesize
From: Eric Dumazet
On small embedded routers, one wants to control maximal amount of
memory used by fq_codel, instead of controlling number of packets or
bytes, since GRO/TSO make these not practical.
Assuming skb->truesize is accurate, we have to keep track of
skb->truesize sum for skbs in queu
10 matches
Mail list logo
