[ovs-dev] [patch net-next RFC 10/12] openvswitch: add support for datapath hardware offload

[Thomas Graf]

On 08/25/14 at 09:53am, Jamal Hadi Salim wrote:
> On 08/24/14 22:42, John Fastabend wrote:
> 
> >In the L2 case we already have the fdb_add and fdb_del semantics that
> >are being used today by NICs with embedded switches. And we have a DSA
> >patch we could dig out of patchwork for those drivers.
> 
> Indeed. That is an excellent starting point of something that is proven
> to work. I was hoping L3 would follow this path. For L2,
> there is the mess of claiming unicast NIC addresses as part of
> the fdb, but that can almost be ignored.
> Caveat: fdb_XXX works well for NICs as well as different larger
> ASICs - but some quark handling is going to be needed for the tinier
> openwrt type devices.
> For larger switches we are going to need more for L2:
> Really, the bridge already covers everthing large switches
> offer (Vlan filtering, bridge port setting etc). We just need
> to offload that...

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.

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.

> >So I think it makes more sense to use the explicit interface rather
> >than put another shim layer in the kernel. Its simpler and more to the
> >point IMO. I suspect the resulting code will be smaller and easier to
> >read. I'm the squemish one in the audience here.
> >
> 
> L2/3 should be left alone and go this path. My concern on excessive
> NDOs was more on the flow view of the world.

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.

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.