From: "Michael S. Tsirkin" <mst@redhat.com>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: John Fastabend <john.fastabend@gmail.com>,
David Miller <davem@davemloft.net>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Jason Wang <jasowang@redhat.com>,
virtualization@lists.linux-foundation.org,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: [PATCH v2] virtio_net: fix PAGE_SIZE > 64k
Date: Wed, 25 Jan 2017 16:23:03 +0200 [thread overview]
Message-ID: <20170125162039-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <CAADnVQ+ioJ7kgsFeFoSV9Nqnq9CkRGMmqS5QM66gsJG01-Rojw@mail.gmail.com>
On Tue, Jan 24, 2017 at 08:07:40PM -0800, Alexei Starovoitov wrote:
> On Tue, Jan 24, 2017 at 7:48 PM, John Fastabend
> <john.fastabend@gmail.com> wrote:
> >
> > It is a concern on my side. I want XDP and Linux stack to work
> > reasonably well together.
>
> btw the micro benchmarks showed that page per packet approach
> that xdp took in mlx4 should be 10% slower vs normal operation
> for tcp/ip stack.
Interesting. TCP only or UDP too? What's the packet size? Are you tuning
your rmem limits at all? The slowdown would be more noticeable with
UDP with default values and small packet sizes.
> We thought that for our LB use case
> it will be an acceptable slowdown, but turned out that overall we
> got a performance boost, since xdp model simplified user space
> and got data path faster, so we magically got extra free cpu
> that is used for other apps on the same host and overall
> perf win despite extra overhead in tcp/ip.
> Not all use cases are the same and not everyone will be as lucky,
> so I'd like to see performance of xdp_pass improving too, though
> it turned out to be not as high priority as I initially estimated.
next prev parent reply other threads:[~2017-01-25 14:23 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-25 4:07 [PATCH v2] virtio_net: fix PAGE_SIZE > 64k Alexei Starovoitov
2017-01-25 14:23 ` Michael S. Tsirkin [this message]
-- strict thread matches above, loose matches on Subject: below --
2017-01-23 19:37 Michael S. Tsirkin
2017-01-24 19:42 ` David Miller
2017-01-24 19:53 ` Michael S. Tsirkin
2017-01-24 20:09 ` David Miller
2017-01-24 20:45 ` Michael S. Tsirkin
2017-01-24 20:53 ` David Miller
2017-01-24 21:07 ` Michael S. Tsirkin
2017-01-24 21:10 ` David Miller
2017-01-24 21:56 ` Michael S. Tsirkin
2017-01-25 3:48 ` John Fastabend
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=20170125162039-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=alexei.starovoitov@gmail.com \
--cc=davem@davemloft.net \
--cc=jasowang@redhat.com \
--cc=john.fastabend@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=virtualization@lists.linux-foundation.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).