public inbox for linux-rdma@vger.kernel.org
 help / color / mirror / Atom feed
From: "Asbjørn Sloth Tønnesen" <ast@fiberby.net>
To: Jakub Kicinski <kuba@kernel.org>
Cc: netdev@vger.kernel.org, "David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Paolo Abeni <pabeni@redhat.com>,
	Edward Cree <ecree.xilinx@gmail.com>,
	Martin Habets <habetsm.xilinx@gmail.com>,
	linux-net-drivers@amd.com, Saeed Mahameed <saeedm@nvidia.com>,
	Leon Romanovsky <leon@kernel.org>,
	Tariq Toukan <tariqt@nvidia.com>,
	linux-rdma@vger.kernel.org,
	Jesse Brandeburg <jesse.brandeburg@intel.com>,
	Tony Nguyen <anthony.l.nguyen@intel.com>,
	intel-wired-lan@lists.osuosl.org,
	Louis Peens <louis.peens@corigine.com>,
	oss-drivers@corigine.com, linux-kernel@vger.kernel.org,
	Davide Caratti <dcaratti@redhat.com>,
	i.maximets@ovn.org
Subject: Re: [PATCH net-next 0/5] net: flower: validate encapsulation control flags
Date: Thu, 13 Jun 2024 17:38:17 +0000	[thread overview]
Message-ID: <711d788e-14e4-41fe-99ea-4c50be008018@fiberby.net> (raw)
In-Reply-To: <20240612180419.391f584d@kernel.org>

Hi Jakub,

On 6/13/24 1:04 AM, Jakub Kicinski wrote:
> On Sun,  9 Jun 2024 17:33:50 +0000 Asbjørn Sloth Tønnesen wrote:
>> Now that all drivers properly rejects unsupported flower control flags
>> used with FLOW_DISSECTOR_KEY_CONTROL, then time has come to add similar
>> checks to the drivers supporting FLOW_DISSECTOR_KEY_ENC_CONTROL.
> 
> Thanks for doing this work!

Thank you, for maintaining the tree!

> Do you have any more of such series left?

Not at the moment, I only stumbled upon this, because I read the code
with an eye on adding a new IS_JUMBO_FRAME flag (patches for which are
almost ready).

Once this[1] currently RFC patch goes in, I might try to move all
control flags in under FLOW_DIS_F_*, to get rid of the then
FLOW_DIS_(IS_FRAGMENT|FIRST_FRAG|ENCAPSULATION|F_*).

[1] [RFC PATCH net-next 1/9] net/sched: flower: define new tunnel flags
https://lore.kernel.org/netdev/20240611235355.177667-2-ast@fiberby.net/

> Could we perhaps consider
> recording the driver support somewhere in struct net_device and do
> the rejecting in the core?

Sure, it could work for the control flags, and used_keys validation,
but I am not sure if it is worth it, as most of the validation is
very specific to the limitations of the different hardware. An easy
first step in that direction would be to move the used_keys checks
behind a helper, and possibly storing used_keys in struct net_device.

> That's much easier to extend when adding
> new flags than updating all the drivers.

That's how it is now, with the new helpers, as all flags are
unsupported, unless the driver specifically supports it.

Any new flag only needs to be added to the core, and drivers only needs
to be updated when they implement offloading support for a flag.

> This series I think may not be a great first candidate as IIUC all
> drivers would reject so the flag would be half-dead...

Correct. I don't know if there is any hardware support planned for the
tunnel-related encapsulation control flags.

-- 
Best regards
Asbjørn Sloth Tønnesen
Network Engineer
Fiberby - AS42541

  reply	other threads:[~2024-06-13 17:38 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-09 17:33 [PATCH net-next 0/5] net: flower: validate encapsulation control flags Asbjørn Sloth Tønnesen
2024-06-09 17:33 ` [PATCH net-next 1/5] flow_offload: add encapsulation control flag helpers Asbjørn Sloth Tønnesen
2024-06-09 17:33 ` [PATCH net-next 2/5] sfc: use flow_rule_is_supp_enc_control_flags() Asbjørn Sloth Tønnesen
2024-06-10 19:31   ` Edward Cree
2024-06-09 17:33 ` [PATCH net-next 3/5] net/mlx5e: flower: validate encapsulation control flags Asbjørn Sloth Tønnesen
2024-06-09 17:33 ` [PATCH net-next 4/5] nfp: " Asbjørn Sloth Tønnesen
2024-06-11  7:24   ` Louis Peens
2024-06-09 17:33 ` [PATCH net-next 5/5] ice: " Asbjørn Sloth Tønnesen
2024-06-10  9:06   ` [Intel-wired-lan] " Marcin Szycik
2024-06-11  9:09 ` [PATCH net-next 0/5] net: " Davide Caratti
2024-06-13  1:04 ` Jakub Kicinski
2024-06-13 17:38   ` Asbjørn Sloth Tønnesen [this message]
2024-06-13  1:10 ` patchwork-bot+netdevbpf

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=711d788e-14e4-41fe-99ea-4c50be008018@fiberby.net \
    --to=ast@fiberby.net \
    --cc=anthony.l.nguyen@intel.com \
    --cc=davem@davemloft.net \
    --cc=dcaratti@redhat.com \
    --cc=ecree.xilinx@gmail.com \
    --cc=edumazet@google.com \
    --cc=habetsm.xilinx@gmail.com \
    --cc=i.maximets@ovn.org \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=jesse.brandeburg@intel.com \
    --cc=kuba@kernel.org \
    --cc=leon@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-net-drivers@amd.com \
    --cc=linux-rdma@vger.kernel.org \
    --cc=louis.peens@corigine.com \
    --cc=netdev@vger.kernel.org \
    --cc=oss-drivers@corigine.com \
    --cc=pabeni@redhat.com \
    --cc=saeedm@nvidia.com \
    --cc=tariqt@nvidia.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