On 08/25/14 10:17, Thomas Graf wrote:
On 08/25/14 at 09:53am, Jamal Hadi Salim wrote:
fdb_add() *is* flow based. At least in my understanding, the whole point here is to extend the idea of fdb_add() and make it understand L2-L4 in a more generic way for the most common protocols. The reason fdb_add() is not reused is because it is Netlink specific and only suitable for User -> HW offload. Kernel -> HW offload is technically possible but not clean.
I dont think we have a problem handling any of this today.
The only reason swdev is needed at all is to represent the port model and to allow for non flow based models built on top of the same hardware abstraction. I see now reason why br_fdb cannot be represented through swdev as soon as the code is stable.
This is where our (shall i say strong) disagreement is. I think you will find it non-trivial to show me how you can actually take the simple L2 bridge and map it to a "flow". Since your starting point is "everything can be represented via a flow and some table" - we are at a crosspath.
The point I was trying to make earlier is that it is very hard to program both protocol aware and generic filtering hardware through a single NDO. It will make the driver specific part complex.
The tc filter API seems to be doing just that. You have different types of classifiers - the h/w may not be able to support some classifier types - but that is a capability discovery challenge.
If you are saying we need yet another classifier model in the kernel then I'm not sure that is needed in the presence of cls/act, iptables, and nftables. They seem suitable to represent non flow based models and I see nothing that would prevent an offload through swdev for them.
I am saying two things: 1) There are a few "fundamental" interfaces; L2 and L3 being some. Add crypto offload and a few i mentioned in my presentation. We know how to do those. example; there is nothing i cant do with the rtmsg that is L3. or the fdb/port/vlan filter for L2. This flow thing should stay out of those. 2) The flow thing should allow a variety of classifiers to be handled. Again capability discovery would take care of differences. cheers, jamal _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
