On 16-02-25 04:56 PM, John Fastabend wrote:
On 16-02-25 04:56 AM, Jamal Hadi Salim wrote:
decoding that is not a problem. The ixgbe driver code already applied can decode that without much trouble. The thing I want to avoid is requiring my driver to do the inverse translation because although it is possible its entirely unnecessary. To do the above example without a software cache for example means I read out row 2048 of a hardware table then you get a bunch of bits. From those bits I consult what fields are being loaded into the table in the packet processing pipeline. I learn its the src_ip fields then I have the value/mask and can unwind it. Finally if I collapsed some hash tables onto this hardware table I have to do the inverse of my collapsing scheme. The ixgbe one is sort of simple just because I only have one table in hardware but with multiple tables its a bit more difficult. Finally I've unwound the thing and can print something back out of 'tc' but it seems easier to just cache the hardware rules somewhere. Maybe other driver/hardware will have a different opinion though depending on how much your firmware can store and how ambitious you are. Personally I don't see any need for the above code.
I think if you can cache the rules and have a way to easily map to the hardware then this would work fine. cheers, jamal
