Re: [RFC PATCH net-next] net: bridge: switchdev: expose the port hwdom as a netlink attribute

[Ido Schimmel <idosch@idosch.org>]

On Thu, Aug 12, 2021 at 04:16:48PM +0000, Vladimir Oltean wrote:
> On Thu, Aug 12, 2021 at 06:35:15PM +0300, Ido Schimmel wrote:
> > Makes sense to me. Gives us further insight into the offload process. I
> > vaguely remember discussing this with Nik in the past. The
> > hwdom/fwd_mark is in the tree for long enough to be considered a stable
> > and useful concept.
> > 
> > You are saying that it is useful to expose despite already having
> > "switchid" exposed because you can have interfaces with the same
> > "switchid" that are not member in the same hardware domain? E.g., the
> > LAG example. If so, might be worth explicitly spelling it out in the
> > commit message.
> 
> Indeed, the "switchid" is static, whereas the "hwdom" depends upon the
> current configuration. So it is useful as a debug feature for the
> reasons you mention, but I am also a bit worried whether we should
> expose this now, since I am not sure if it will impact future redesigns
> of the bridge driver or switchdev (the hwdom is a pretty detailed bit of
> information). Basically the only guarantee we're giving user space is
> that a hwdom of zero means unoffloaded, and two non-zero and equal
> integer values can forward between each other without involving the CPU.
> The numbers themselves are arbitrary, mean nothing and can vary even
> depending on the port join order into the bridge. That shouldn't impose
> any restrictions going further, should it?

Not that I'm aware. On the other hand, I didn't see a pressing need to
expose this attribute either so we can wait a bit longer to gain more
confidence if you want.