All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Valente <paolo.valente@unimore.it>
To: Cong Wang <amwang@redhat.com>
Cc: netdev@vger.kernel.org, Stephen Hemminger <shemminger@vyatta.com>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: [RFC PATCH net-next] qfq: handle the case that front slot is empty
Date: Fri, 26 Oct 2012 09:51:36 +0200	[thread overview]
Message-ID: <58DEB62C-6237-435E-8300-8E390F101F58@unimore.it> (raw)
In-Reply-To: <1350982432.26308.8.camel@cr0>


Il giorno 23/ott/2012, alle ore 10:53, Cong Wang ha scritto:

> On Tue, 2012-10-23 at 09:09 +0200, Paolo Valente wrote:
>> The crash you reported is one of the problems I tried to solve with my last fixes.
>> After those fixes I could not reproduce this crash (and other crashes) any more, but of course I am still missing something.
> 
> I am using the latest net-next, so if your patches are in net-next,
> then the problem of course still exists.
> 
>> 
>> Il giorno 23/ott/2012, alle ore 06:15, Cong Wang ha scritto:
>> 
>>> I am not sure if this patch fixes the real problem or just workarounds
>>> it. At least, after this patch I don't see the crash I reported any more.
>> 
>> It is actually a workaround: if the condition that triggers your workaround holds true, then the group data structure is already inconstent, and qfq is likely not to schedule classes correctly.
>> I will try to reproduce the crash with the steps you suggest, and try to understand what is still wrong as soon as I can.
>> 
> 
> OK, I don't pretend I understand qfq.
The problem is that I should :)
> And I can help you to test
> patches.
> 
I think I will ask for your help soon, thanks.

The cause of the failure is TCP segment offloading, which lets qfq receive packets with a much larger size than the MTU of the device.
In this respect, under qfq the default max packet size lmax for each class (2KB) is only slightly higher than the MTU. Violating the lmax constraint causes the corruption of the data structure that implements the bucket lists of the groups. In fact, the failure that you found is only one of the consequences of this corruption. I am sorry I did not discover it before, but, foolishly, I have run only UDP tests.

I am thinking about the best ways for addressing this issue.

BTW, I think that the behavior of all the other schedulers should be checked as well. For example, with segment offloading, drr must increment the deficit of a class for at most (64K/quantum) times, i.e., rounds, before it can serve the next packet of the class. The number of instructions per packet dequeue becomes therefore (64K/quantum) times higher than without segment offloading.

> Thanks!
> 

  reply	other threads:[~2012-10-26  7:53 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-23  4:15 [RFC PATCH net-next] qfq: handle the case that front slot is empty Cong Wang
2012-10-23  7:09 ` Paolo Valente
2012-10-23  8:53   ` Cong Wang
2012-10-26  7:51     ` Paolo Valente [this message]
2012-10-26  8:10       ` Eric Dumazet
2012-10-26  9:32         ` [PATCH net-next] net_sched: more precise pkt_len computation Eric Dumazet
2012-10-26 11:11           ` Eric Dumazet
2013-01-10 22:36           ` [PATCH v2 " Eric Dumazet
2013-01-10 22:58             ` David Miller
2012-10-26 16:51     ` [RFC PATCH net-next] qfq: handle the case that front slot is empty Paolo Valente
2012-10-28 12:45       ` Cong Wang
2012-10-28 16:07         ` Paolo Valente

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=58DEB62C-6237-435E-8300-8E390F101F58@unimore.it \
    --to=paolo.valente@unimore.it \
    --cc=amwang@redhat.com \
    --cc=davem@davemloft.net \
    --cc=eric.dumazet@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=shemminger@vyatta.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.