From: Jesper Dangaard Brouer <jbrouer@redhat.com>
To: Denis Salopek <Denis.Salopek@fer.hr>
Cc: "xdp-newbies@vger.kernel.org" <xdp-newbies@vger.kernel.org>,
Alexander Duyck <alexander.duyck@gmail.com>
Subject: Re: XDP_REDIRECT forwarding speed
Date: Tue, 26 May 2020 10:04:43 +0200 [thread overview]
Message-ID: <20200526100443.2c927057@carbon> (raw)
In-Reply-To: <AM0PR08MB3345DF6A3FABBCF262B39E968BB00@AM0PR08MB3345.eurprd08.prod.outlook.com>
On Tue, 26 May 2020 07:00:30 +0000
Denis Salopek <Denis.Salopek@fer.hr> wrote:
> I want to make sure I did everything right to make my XDP program
> (simple forwarding with bpf_redirect_map) as fast as possible. Is following
> advices and gotchas from this:
> https://www.mail-archive.com/netdev@vger.kernel.org/msg184139.html
I prefer links to lore.kernel.org:
[1] https://lore.kernel.org/netdev/20170821212506.1cb0d5d6@redhat.com/
Do notice that my results in [1] is for a single queue and single CPU.
In production I assume that you can likely scale this across more CPUs ;-)
> enough or are there some additional/newer recommendations? I managed
> to get near line-rate on my Intel X520s (on Ryzen 3700X and one
> queue/CPU), but not quite 14.88 Mpps so I was wondering is there
> something else to speed things up even more.
In [1] I mention the need to tune the TX-queue to keep up via either
adjusting the TX-DMA completion interrupt interval:
Tuned with rx-usecs 25:
ethtool -C ixgbe1 rx-usecs 25 ;\
ethtool -C ixgbe2 rx-usecs 25
Or increasing the size of the TX-queue, so it doesn't overrun:
Tuned with adjusting ring-queue sizes:
ethtool -G ixgbe1 rx 1024 tx 1024 ;\
ethtool -G ixgbe2 rx 1024 tx 1024
This might not be needed any longer, as I think it was Alexander, that
implemented an improved interrupt adjustment scheme for ixgbe.
> Also, are there any recommended settings/tweaks for bidirectional
> forwarding? I suppose there would be a drop in performance compared to
> single direction, but has anyone done any benchmarks?
As this was 1-CPU you can just run the other direction on another CPU.
That said, it can still be an advantage to run the bidirectional
traffic on the same CPU and RX-TX-queue pair, as above issue with
TX-queue DMA cleanups/completions goes away. Because, the ixgbe driver
will do TX-cleanups as part (before) the RX-processing.
What is your use-case?
e.g. building an IPv4 router?
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
next prev parent reply other threads:[~2020-05-26 8:04 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-26 7:00 XDP_REDIRECT forwarding speed Denis Salopek
2020-05-26 8:04 ` Jesper Dangaard Brouer [this message]
2020-05-26 11:09 ` Denis Salopek
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=20200526100443.2c927057@carbon \
--to=jbrouer@redhat.com \
--cc=Denis.Salopek@fer.hr \
--cc=alexander.duyck@gmail.com \
--cc=xdp-newbies@vger.kernel.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 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.