From: Leon Romanovsky <leon@kernel.org>
To: Jakub Kicinski <kuba@kernel.org>
Cc: Steffen Klassert <steffen.klassert@secunet.com>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Herbert Xu <herbert@gondor.apana.org.au>,
netdev@vger.kernel.org, Paolo Abeni <pabeni@redhat.com>,
Raed Salem <raeds@nvidia.com>, Saeed Mahameed <saeedm@nvidia.com>
Subject: Re: [PATCH xfrm-next v3 0/6] Extend XFRM core to allow full offload configuration
Date: Fri, 26 Aug 2022 09:26:57 +0300 [thread overview]
Message-ID: <YwhnsWtzwC/wLq1i@unreal> (raw)
In-Reply-To: <20220825143610.4f13f730@kernel.org>
On Thu, Aug 25, 2022 at 02:36:10PM -0700, Jakub Kicinski wrote:
> On Tue, 23 Aug 2022 16:31:57 +0300 Leon Romanovsky wrote:
> > * I didn't hear any suggestion what term to use instead of
> > "full offload", so left it as is. It is used in commit messages
> > and documentation only and easy to rename.
> > * Added performance data and background info to cover letter
> > * Reused xfrm_output_resume() function to support multiple XFRM transformations
> > * Add PMTU check in addition to driver .xdo_dev_offload_ok validation
> > * Documentation is in progress, but not part of this series yet.
>
> Since the use case is somewhat in question, perhaps switch to RFC
> postings until the drivers side incl. tc forwarding is implemented?
Proposed driver implementation works fine with eswitch representors.
All our flow steering magic is performed on local table entry and it
ensures that representors receives/sends "clean" traffic.
We are using the following configuration snippet to achieve that.
---------------------------------------------------------------------
#!/bin/bash
P0_OUTER_REMOTE_IP=192.168.50.2
P0_OUTER_LOCAL_IP=192.168.50.1
PF0=enp8s0f0
VF0_REP=enp8s0f0_0
set -v
# Configure IP and turn VF_REP on
ifconfig $PF0 $P0_OUTER_LOCAL_IP/24 up
ifconfig $VF0_REP up
# Clean all TC rules, start fresh
tc qdisc del dev enp8s0f0 ingress >/dev/null 2>&1
tc qdisc del dev enp8s0f0_0 ingress >/dev/null 2>&1
# Make sure steering mode is dmfs(FW) and eswitch encap is none
devlink dev param set pci/0000:08:00.0 name flow_steering_mode value dmfs cmode runtime
devlink dev eswitch set pci/0000:08:00.0 mode legacy
devlink dev eswitch set pci/0000:08:00.0 encap none
devlink dev eswitch set pci/0000:08:00.0 mode switchdev
sleep 2
tc qdisc add dev enp8s0f0 ingress
tc qdisc add dev enp8s0f0_0 ingress
# Add TC rules
tc filter add dev $PF0 parent ffff: protocol 802.1q chain 0 flower vlan_id 10 vlan_ethtype 802.1q cvlan_id 5 action vlan pop action vlan pop action mirred egress redirect dev $VF0_REP
tc filter add dev $VF0_REP parent ffff: protocol all chain 0 flower action vlan push protocol 802.1q id 5 action vlan push protocol 802.1q id 10 action mirred egress redirect dev $PF0
tc filter show dev $PF0 ingress
----------------------------------------------------------------------------------------------------
We also don't offload anything related to routing as we can't
differentiate between local traffic.
> Also the perf traces, I don't see them here.
It is worth to separate it to standalone discussion with a title:
"why crypto is not fast enough?". I don't think that mixed discussions
about full offload which Steffen said that he is interested and
research about crypto bottlenecks will be productive. These discussions
are orthogonal.
Thanks
next prev parent reply other threads:[~2022-08-26 6:27 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-23 13:31 [PATCH xfrm-next v3 0/6] Extend XFRM core to allow full offload configuration Leon Romanovsky
2022-08-23 13:31 ` [PATCH xfrm-next v3 1/6] xfrm: add new full offload flag Leon Romanovsky
2022-08-23 13:31 ` [PATCH xfrm-next v3 2/6] xfrm: allow state full offload mode Leon Romanovsky
2022-08-23 13:32 ` [PATCH xfrm-next v3 3/6] xfrm: add an interface to offload policy Leon Romanovsky
2022-08-23 13:32 ` [PATCH xfrm-next v3 4/6] xfrm: add TX datapath support for IPsec full offload mode Leon Romanovsky
2022-08-23 13:32 ` [PATCH xfrm-next v3 5/6] xfrm: add RX datapath protection " Leon Romanovsky
2022-08-23 13:32 ` [PATCH xfrm-next v3 6/6] xfrm: enforce separation between priorities of HW/SW policies Leon Romanovsky
2022-08-25 21:36 ` [PATCH xfrm-next v3 0/6] Extend XFRM core to allow full offload configuration Jakub Kicinski
2022-08-26 6:26 ` Leon Romanovsky [this message]
2022-08-26 23:45 ` Jakub Kicinski
2022-08-28 9:28 ` Leon Romanovsky
2022-08-30 17:36 ` Jason Gunthorpe
2022-08-30 18:56 ` Jakub Kicinski
2022-08-30 22:34 ` Jason Gunthorpe
2022-08-29 8:07 ` Steffen Klassert
2022-08-29 7:54 ` Steffen Klassert
2022-08-30 6:48 ` Leon Romanovsky
2022-09-04 16:45 ` Leon Romanovsky
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=YwhnsWtzwC/wLq1i@unreal \
--to=leon@kernel.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=herbert@gondor.apana.org.au \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=raeds@nvidia.com \
--cc=saeedm@nvidia.com \
--cc=steffen.klassert@secunet.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 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).