On Sat, 27 Feb 2021 02:16:51 +0200 Vladimir Oltean wrote: > On Fri, Feb 26, 2021 at 03:49:22PM -0800, Jakub Kicinski wrote: > > On Sat, 27 Feb 2021 01:42:44 +0200 Vladimir Oltean wrote: > > > What I'm fixing is unexpected behavior, according to the applicable > > > standards I could find. If I don't mark this change as a bug fix but as > > > a simple patch, somebody could claim it's a regression, since promiscuity > > > used to be enough to see packets with unknown VLANs, and now it no > > > longer is... > > > > Can we take it into net-next? What's your feeling on that option? > > I see how you can view this patch as pointless, but there is some > context to it. It isn't just for tcpdump/debugging, instead NXP has some > TSN use cases which involve some asymmetric tc-vlan rules, which is how > I arrived at this topic in the first place. I've already established > that tc-vlan only works with ethtool -K eth0 rx-vlan-filter off: > https://lore.kernel.org/netdev/ca+h21hoxwrdhq4y+w8kwgm74d4ca0xleihtrmt-vpsam7ob...@mail.gmail.com/ > and that's what we recommend doing, but while adding the support for > rx-vlan-filter in enetc I accidentally created another possibility for > this to work on enetc, by turning IFF_PROMISC on. This is not portable, > so if somebody develops a solution based on that in parallel, it will > most certainly break on other non-enetc drivers. > NXP has not released a kernel based on the v5.10 stable yet, so there is > still time to change the behavior, but if this goes in through net-next, > the apparent regression will only be visible when the next LTS comes > around (whatever the number of that might be). Now, I'm going to > backport this to the NXP v5.10 anyway, so that's not an issue, but there > will still be the mild annoyance that the upstream v5.10 will behave > differently in this regard compared to the NXP v5.10, which is again a > point of potential confusion, but that seems to be out of my control. > > So if you're still "yeah, don't care", then I guess I'm ok with leaving > things alone on stable kernels.
I see, so this is indeed of practical importance to NXP. Would you mind re-spinning with an expanded justification?
