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
