Messages in this thread | | | From | Vladimir Oltean <> | Subject | Re: [PATCH net-next v8 3/5] net: dsa: add out-of-band tagging protocol | Date | Mon, 7 Nov 2022 11:27:37 +0000 |
| |
Hi Jakub,
On Fri, Nov 04, 2022 at 08:05:30PM -0700, Jakub Kicinski wrote: > On Fri, 4 Nov 2022 18:41:49 +0100 Maxime Chevallier wrote: > > Add a new tagging protocol based on SKB extensions to convey the > > information about the destination port to the MAC driver > > This is what METADATA_HW_PORT_MUX is for, you shouldn't have > to allocate a piece of memory for every single packet.
Since this is the model that skb extensions propose and not something that Maxime invented for this series, I presume that's not such a big deal? What's more, couldn't this specific limitation of skb extensions be addressed in a punctual way, via one-time calls to __skb_ext_alloc() and fast path calls to __skb_ext_set()?
I'm unfamiliar to the concept of destination cache entries and even more so to the concept of struct dst_entry * carrying metadata. I suppose the latter were introduced for lack of space in struct sk_buff, to carry metadata between layers that aren't L3/L4 (where normal dst_entry structs are used)? What makes metadata dst's preferable to skb extensions? The latter are more general; AFAIK they can be used between any layer and any other layer, like for example between RX and TX in the forwarding path. Side note, I am not exactly clear what are the lifetime guarantees of a metadata dst entry, and if DSA's use would be 100% safe (DSA is kind of L3, since it has an ETH_P_XDSA packet_type handler, not an rx_handler).
More importantly, what happens if a DSA switch is used together with a SRIOV-capable DSA master which already uses METADATA_HW_PORT_MUX for PF-VF communication? (if I understood the commit message of 3fcece12bc1b ("net: store port/representator id in metadata_dst") correctly)
| |