All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sabrina Dubroca <sd@queasysnail.net>
To: Cosmin Ratiu <cratiu@nvidia.com>
Cc: "pabeni@redhat.com" <pabeni@redhat.com>,
	"andrew+netdev@lunn.ch" <andrew+netdev@lunn.ch>,
	"davem@davemloft.net" <davem@davemloft.net>,
	"linux-kselftest@vger.kernel.org"
	<linux-kselftest@vger.kernel.org>,
	Dragos Tatulea <dtatulea@nvidia.com>,
	"shuah@kernel.org" <shuah@kernel.org>,
	"sdf@fomichev.me" <sdf@fomichev.me>,
	"kuba@kernel.org" <kuba@kernel.org>,
	"horms@kernel.org" <horms@kernel.org>,
	"edumazet@google.com" <edumazet@google.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: [PATCH net v6 4/4] macsec: Support VLAN-filtering lower devices
Date: Wed, 8 Apr 2026 10:25:00 +0200	[thread overview]
Message-ID: <adYQ3OMfEEWFTd7X@krikkit> (raw)
In-Reply-To: <e2eefeb7033caa859551834d3448a77b7af3c7d4.camel@nvidia.com>

2026-04-07, 15:07:47 +0000, Cosmin Ratiu wrote:
> On Thu, 2026-04-02 at 16:48 +0200, Sabrina Dubroca wrote:
> > If this happens on a real device, the VLAN filters will be broken.
> > I'm
> > not sure what the right behavior would be:
> > 
> > 1. reject the request to enable offload
> > 2. switch to promiscuous mode
> 
> I implemented and tested option 1. In the unlikely scenario adding VLAN
> filters prevents offloading

How unlikely is it? Resource allocation, talking to HW, device limits,
anything else that could fail?

> , it's better for the driver to be explicit
> and let the user turn on promisc mode themselves. Keeping track of
> whether VLAN filters failed and promisc was used as a fallback adds
> some extra complexity.

If it's indeed (very) unlikely, sure. There's still a bit of a
regression/change of behavior for users compared to before the
IFF_UNICAST_FLT patch, but I think we can wait until someone
complains, and then add the tracking if that happens.

> What would be the point of IFF_UNICAST_FLT then?

The point is that this would just be a fallback.

> Please let me know if you agree with this approach, so I can send v8
> with it.

If you can confirm it's on the "very unlikely" side, yes, this
approach sounds ok. Thanks.

> > OTOH maybe we don't need to care, since __netdev_update_features also
> > (kind of) ignores those errors:
> > 
[...]
> 
> Well, in this case we have the chance to do something nicer (even
> proper error message back to the user via extack) for a small

(That reminds me I have a branch of "macsec: add extack to X" patches
I still need to polish and submit. I don't think I'll get to it before
the merge window opens, I'll rebase on top of your changes.)

> complexity cost. Perhaps the VLAN filter handling could be improved
> separately.

I'm not sure if this would be an "improvement to VLAN filter handling"
or a "(breaking) change of user-visible behavior". Probably
improvement. Or maybe it's "unlikely enough" that nobody has ever
cared.

-- 
Sabrina

  reply	other threads:[~2026-04-08  8:25 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-30 13:01 [PATCH net v6 0/4] macsec: Add support for VLAN filtering in offload mode Cosmin Ratiu
2026-03-30 13:01 ` [PATCH net v6 1/4] selftests: Migrate nsim-only MACsec tests to Python Cosmin Ratiu
2026-04-02 10:03   ` Sabrina Dubroca
2026-04-02 11:51     ` Cosmin Ratiu
2026-03-30 13:01 ` [PATCH net v6 2/4] nsim: Add support for VLAN filters Cosmin Ratiu
2026-04-02 10:09   ` Sabrina Dubroca
2026-03-30 13:01 ` [PATCH net v6 3/4] selftests: Add MACsec VLAN propagation traffic test Cosmin Ratiu
2026-04-02 11:37   ` Sabrina Dubroca
2026-04-02 14:18     ` Cosmin Ratiu
2026-03-30 13:01 ` [PATCH net v6 4/4] macsec: Support VLAN-filtering lower devices Cosmin Ratiu
2026-04-02 14:48   ` Sabrina Dubroca
2026-04-07 15:07     ` Cosmin Ratiu
2026-04-08  8:25       ` Sabrina Dubroca [this message]
2026-04-08 10:24         ` Cosmin Ratiu
2026-04-08 11:01           ` Sabrina Dubroca
2026-04-02  2:54 ` [PATCH net v6 0/4] macsec: Add support for VLAN filtering in offload mode Jakub Kicinski

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=adYQ3OMfEEWFTd7X@krikkit \
    --to=sd@queasysnail.net \
    --cc=andrew+netdev@lunn.ch \
    --cc=cratiu@nvidia.com \
    --cc=davem@davemloft.net \
    --cc=dtatulea@nvidia.com \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=sdf@fomichev.me \
    --cc=shuah@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.