Hi all, (apologies for the long CC list and the fact that I can't type correctly email addresses)
While working on adding support for the Broadcom Ethernet switches Compact Field Processor (which is essentially a TCAM, action/policer/rate meter RAMs, 256 entries), I started working with the ethtool::rxnfc API which is actually kind of nice in that it fits nicely with my use simple case of being able to insert rules at a given or driver selected location and has a pretty good flow representation for common things you may match: TCP/UDP v4/v6 (not so much for non-IP, or L2 stuff though you can use the extension flow representation). It lacks support for more complex actions other than redirect to a particular port/queue. Now ethtool::rxnfc is one possible user, but tc and netfiler also are, more powerful and extensible, but since this is a resource constrained piece of hardware, and it would suck for people to have to implement these 3 APIs if we could come up with a central one that satisfies the superset offered by tc + netfilter. We can surely imagine an use case we centralize the whole matching + action into a Domain Specific Language that we compiled into eBPF and then translate into whatever the HW understands, although that raises the question of where do we put the translation tool in user space or kernel space. So what's everybody's take on this? Thanks! -- Florian
