On 12/15/14 at 02:29pm, Varlese, Marco wrote:yes, exactly.
Excellent, I agree with what you are saying. What set me off is thatAll of these are highly generic and should *not* be passed through from userHow 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?
space to the driver directly but rather be properly abstracted as Roopa
proposed. The value of this API is abstraction.
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.
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
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