Re: [RFC PATCH net-next 1/1] net: Support for switch port configuration

From: Roopa Prabhu
Date: Mon Dec 15 2014 - 11:44:34 EST

On 12/15/14, 6:40 AM, Thomas Graf wrote:
On 12/15/14 at 02:29pm, Varlese, Marco wrote:
All of these are highly generic and should *not* be passed through from user
space to the driver directly but rather be properly abstracted as Roopa
proposed. The value of this API is abstraction.
How would you let the user enable/disable features then? For instance, how would the user enable/disable flooding for broadcast packets (BFLOODING) on a given port? What I was proposing is to have a list of attributes (to be added in if_link.h) which can be tuned by the user using a tool like iproute2. What do you propose?
Excellent, I agree with what you are saying. What set me off is that
the patch does not reflect that yet. Instead, the patch introduces
a pure Netlink pass-through API to the driver.

I would expect the patch to:
1. Parse the Netlink messages and be aware of individual attributes
2. Validate them
3. Pass the configuration to the driver using an API that can also
be consumed from in-kernel users.
yes, exactly.

I think I have seen Roopa posting his updated ndo patch and getting some feedback by few people already and as long as I will be able to accomplish the use case described here I am happy with his way.
I think Roopa's patches are supplementary. Not all switchdev users
will be backed with a Linux Bridge. I therefore welcome your patches
very much.

The overlap is in the ndo. I think both the API you propose and
Roopa's bridge code should use the same NDO.
I do not have an example right now of a vendor specific attribute but I was just saying that might happen (i.e. someone will have a feature not implemented by others?).
That's fine. Once we have them we can consider adding vendor specific

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at