On 16-07-18 06:07 AM, Thomas Graf wrote:
Right. I was at the same point as Jamal and it is nasty to try and reverse engineer the dumps without any further hints. I assume that's what he is referring to with difficulties.
That +: if you get me a field which says "dstmac" i dont have to go and start aggregating 32bit chunks to create a 48bit MAC (or worse look at the offset and figure where they come from).
Looking back, I would simply calculate a SHA hash over the original filter in text form, pass the hash together with the tc filter and then associate the hash with the filter text stored in user space. This would not only benefit pedit but also u32 and possibly others.
A "cookie" tag that is sent to the kernel would serve the purpose. We would need to standardize what the meaning of such a cookie is.
It also has the advantage that extending the kernel once now will allow to add additional higher level abstractions later on without requiring users to rebase their kernels.
Yes - and btw it works well with hardware offloads. It is a good free form "assembler" level. But i dont think it serves well when we have known often-used cases such as these. It is like doing tcp over raw sockets - at some point it becomes more efficient and more usable to just introduce tcp sockets. Thats all I am asking for. cheers, jamal
