On 14/02/19 12:39, Jamal Hadi Salim wrote: > On 2019-02-11 6:44 a.m., Edward Cree wrote: >> My end goal is to implement TC offload in some hw we're designing >> here at Solarflare. So I'm trying to determine what hardware is >> expected/required to do. >> It might be possible to design our new hw so that we can attach a >> counter to every action, if that's what TC wants. > > It makes sense to have a counter on every action - even if it is > for debugging purposes. The two most basic actions are "drop" or > "accept". In TC speak the default action is "classid x:y" which > typically is to select a queue or give the flow some identity Perhaps I was insufficiently clear; we're only looking at the switching side of things (e.g. OVS offload) right now; we don't yet have a plan for 'delivery' filters (I imagine we'll probably initially port over our ethtool ntuple filter handling from ef10, though we may end up going down the TC route there). So I think at the moment 'classid' isn't relevant (?)
> Note, your counters should also be shareable; example, count all > the drops in one counter across multiple flows as in the following > case where counter index 1 is used. > > tc flower match foo action drop index 1 > tc flower match bar action drop index 1 [...] > allow them to specify > the counter index (assuming you architecture has an indexed table > of counters). Our architecture allocates objects (including counters) and returns opaque handles to them, so we'd need a software table to connect counter index to FW counter ID. Also, sharing counters in hw causes extra work for the driver code that keeps track of which encap actions are getting hit (so it can keep the neighbour entries alive). Maybe summing the shared counters in sw is easier than that, I'm not sure (or maybe encap action counters should just be kept separate from the counters we report to TC). TBH I'm coming to the conclusion that what we should do for the first version of our driver is just to create a counter per rule and report it against the first action (only), and for now ignore the index (or maybe require it to be set to some distinguished value, like 0, to mean 'allocate', so that as a future extension we can support shareable counters). -Ed
