netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Niklas Söderlund" <niklas.soderlund@corigine.com>
To: Jakub Kicinski <kuba@kernel.org>
Cc: Simon Horman <simon.horman@corigine.com>,
	David Miller <davem@davemloft.net>,
	netdev@vger.kernel.org, oss-drivers@corigine.com,
	Yu Xiao <yu.xiao@corigine.com>,
	Yinjun Zhang <yinjun.zhang@corigine.com>,
	Louis Peens <louis.peens@corigine.com>
Subject: Re: [PATCH net] nfp: bpf: Add an MTU check before offloading BPF
Date: Thu, 30 Sep 2021 16:46:34 +0200	[thread overview]
Message-ID: <YVXNype34MW7Swu3@bismarck.dyn.berto.se> (raw)
In-Reply-To: <20210929114748.545f7328@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>

Hello Jackub,

Thanks for your feedback.

On 2021-09-29 11:47:48 -0700, Jakub Kicinski wrote:
> On Wed, 29 Sep 2021 17:24:21 +0200 Simon Horman wrote:
> > From: Yu Xiao <yu.xiao@corigine.com>
> > 
> > There is a bug during xdpoffloading. When MTU is bigger than the
> > max MTU of BFP (1888), it can still be added xdpoffloading.
> > 
> > Therefore, add an MTU check to ensure that xdpoffloading cannot be
> > loaded when MTU is larger than a max MTU of 1888.
> 
> There is a check in nfp_net_bpf_load(). TC or XDP, doesn't matter,
> we can't offload either with large MTU since the FW helper (used to be) 
> able to only access CTM. So the check is on the generic path, adding
> an XDP-specific check seems wrong.

I understand your point and it make sens. The check in 
nfp_net_bpf_load() in the generic path do indeed check for this, but in 
a slightly different way. It verifies that the BPF program don't access 
any data that is not in CMT.

The original problem this patch tried to address was to align the 
behavior that the MTU is verified differently when the BPF program is 
loaded and when the MTU is changed once the program is loaded.

Without this patch we had the following behavior,

    # ip link set ens5np0 mtu 9000
    # ip link set dev ens5np0 xdpoffload obj bpf_prog.o sec testcase
    # ip link show dev ens5np0
    11: ens5np0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 xdpoffload qdisc mq state UP mode DEFAULT group default qlen 1000
	link/ether 00:15:4d:13:61:91 brd ff:ff:ff:ff:ff:ff
	prog/xdp id 48 tag 57cd311f2e27366b jited
    # ip link set ens5np0 mtu 1500
    # ip link set ens5np0 mtu 9000
    RTNETLINK answers: Device or resource busy
    # ip link set ens5np0 mtu 1888
    # ip link show dev ens5np0
    11: ens5np0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1888 xdpoffload qdisc mq state UP mode DEFAULT group default qlen 1000
        link/ether 00:15:4d:13:61:91 brd ff:ff:ff:ff:ff:ff
        prog/xdp id 48 tag 57cd311f2e27366b jited 

When the MTU is changed after the program is offloaded the check in 
nfp_bpf_check_mtu() is consulted and as it checks the MTU differently 
and fails the change. Maybe we should align this the other way around 
and update the check in nfp_bpf_check_mtu() to match the one in 
nfp_net_bpf_load()?

On a side note the check in nfp_net_bpf_load() allows for BPF programs 
to be offloaded that do access data beyond the CMT size limit provided 
the MTU is set below the CMT threshold value. There should be no real 
harm in this as the verifier forces bounds check so with a MTU small 
enough it should never happen. But maybe we should add a check for this 
too to prevent such a program to be loaded in the first place.

Thanks again for your input.

-- 
Regards,
Niklas Söderlund

  reply	other threads:[~2021-09-30 14:46 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-29 15:24 [PATCH net] nfp: bpf: Add an MTU check before offloading BPF Simon Horman
2021-09-29 18:47 ` Jakub Kicinski
2021-09-30 14:46   ` Niklas Söderlund [this message]
2021-09-30 14:59     ` Jakub Kicinski
2021-09-30 15:15       ` Niklas Söderlund

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=YVXNype34MW7Swu3@bismarck.dyn.berto.se \
    --to=niklas.soderlund@corigine.com \
    --cc=davem@davemloft.net \
    --cc=kuba@kernel.org \
    --cc=louis.peens@corigine.com \
    --cc=netdev@vger.kernel.org \
    --cc=oss-drivers@corigine.com \
    --cc=simon.horman@corigine.com \
    --cc=yinjun.zhang@corigine.com \
    --cc=yu.xiao@corigine.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).