On Mon, Nov 07, 2022 at 08:49:34AM -0800, Jakub Kicinski wrote:
On Mon, 7 Nov 2022 12:51:26 +0000 Vladimir Oltean wrote:
quoted
There is also another problem having to do with future extensibility of
METADATA_HW_PORT_MUX for DSA. I don't know how much of this is going to
be applicable for qca8k, but DSA tags might also carry such information
as trap reason (RX) or injection type (into forwarding plane or control
packet; the latter bypasses port STP state) and the FID to which the
packet should be classified by the hardware (TX). If we're going to
design a mechanism which only preallocates metadata dst's for ports,
it's going to be difficult to make that work for more information later on.
The entire patch we're commenting on is 100 LoC. Seems like a small
thing, which can be rewritten later as needed. I don't think hand wave-y
arguments are sufficient to go with a much heavier solution from the
start.
I don't think it's as hand wavey as you think. Maxime did not present
the switch-side changes or device tree in this patch set. If it's going
to be based on drivers/net/dsa/qca/qca8k-common.c as I suspect, then it
might have some obscure features which are already supported by 'normal'
QCA8K DSA switches, like register read/write over Ethernet, and MIB
autocasting. If these features exist in hardware (they aren't exposed by
this patch set for sure), you'd be hard-pressed to fit them into the
METADATA_HW_PORT_MUX model, since it's pure management traffic consumed
by the switch driver and not delivered to the network stack, as opposed
to packets sent/received on behalf of any switch port.