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.
> 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
extensions.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
