From: Arnd Bergmann <arnd@arndb•de>
To: Herbert Xu <herbert@gondor•apana.org.au>
Cc: "David S. Miller" <davem@davemloft•net>,
netdev@vger•kernel.org, Mark Wagner <mwagner@redhat•com>,
Chris Wright <chrisw@sous-sol•org>
Subject: Re: macvtap: Limit packet queue length
Date: Thu, 22 Jul 2010 11:30:53 +0200 [thread overview]
Message-ID: <201007221130.53612.arnd@arndb.de> (raw)
In-Reply-To: <20100722074431.GA26744@gondor.apana.org.au>
On Thursday 22 July 2010, Herbert Xu wrote:
> On Thu, Jul 22, 2010 at 02:41:57PM +0800, Herbert Xu wrote:
> > Hi:
> >
> > macvtap: Limit packet queue length
>
> Chris has informed me that he's already tried a similar patch
> and it only makes the problem worse :)
>
> The issue is that the macvtap TX queue length defaults to zero.
>
> So here is an updated patch which addresses this:
Thanks for debugging this and coming up with a solution.
I'm currently travelling, so I can't easily work on it myself.
> Please note that macvtap currently has no way of giving congestion
> notification, that means the software device TX queue cannot be
> used and packets will always be dropped once the macvtap driver
> queue fills up.
This is something I was planning to look into for doing it right,
and then I forgot about it. I'll investigate what could be done
to get proper flow control once I get back to the office.
> Chris Wright noticed that for this patch to work, we need a
> non-zero TX queue length. This patch includes his work to change
> the default macvtap TX queue length to 500.
The only problem I can see with this patch is making it depend on
the *TX* queue length. The point is that unlike tun/tap, the
macvtap network interface's point of view is that this is the
receive queue, not the transmit queue.
In the TX direction, we really don't queue, since we simply forward
to the lowerdev tx queue, so exposing the tunable to user space
as the tx queue length is a little bit awkward, as well as inconsistent
between macvtap and macvlan.
> Reported-by: Mark Wagner <mwagner@redhat•com>
> Signed-off-by: Herbert Xu <herbert@gondor•apana.org.au>
As long as we're missing a better solution,
Acked-by: Arnd Bergmann <arnd@arndb•de>
next prev parent reply other threads:[~2010-07-22 9:31 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-22 6:41 macvtap: Limit packet queue length Herbert Xu
2010-07-22 7:44 ` Herbert Xu
2010-07-22 7:47 ` Chris Wright
2010-07-22 9:30 ` Arnd Bergmann [this message]
2010-07-22 16:05 ` Shirley Ma
2010-07-22 16:08 ` Herbert Xu
2010-07-22 18:42 ` Shirley Ma
2010-07-22 20:09 ` David Miller
2010-07-22 15:59 ` Shirley Ma
2010-07-22 16:07 ` Herbert Xu
2010-07-22 19:58 ` David Miller
2010-07-23 7:28 ` Arnd Bergmann
2010-07-23 7:58 ` Herbert Xu
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=201007221130.53612.arnd@arndb.de \
--to=arnd@arndb$(echo .)de \
--cc=chrisw@sous-sol$(echo .)org \
--cc=davem@davemloft$(echo .)net \
--cc=herbert@gondor$(echo .)apana.org.au \
--cc=mwagner@redhat$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox