On 16-02-25 03:05 PM, Jamal Hadi Salim wrote: > 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.
Yep that is the goal. I think the debate is if its acceptable to do it with an entirely new filter list ingress_hw Jiri's opinion is that it would be best to do it inline inside the classifier. At the moment I'm looking at the code to see if there is a clean way to do it. IMO using a ingress_hw classifier is a nice solution. In the meantime I just respun patches 1-3 with the feedback and will submit those while I work out patch 4. > > cheers, > jamal
