Thread (4 messages) flat view 4 messages, 2 authors, 2021-08-16

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

From: Vladimir Oltean <vladimir.oltean@nxp.com>
Date: 2021-08-12 16:16:54

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?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help