lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 9 Feb 2016 07:20:04 -0500 From: Jamal Hadi Salim <jhs@...atatu.com> To: "Fastabend, John R" <john.fastabend@...il.com>, Or Gerlitz <ogerlitz@...lanox.com> Cc: amir@...ai.me, jiri@...nulli.us, jeffrey.t.kirsher@...el.com, netdev@...r.kernel.org, davem@...emloft.net Subject: Re: [net-next PATCH 0/7] tc offload for cls_u32 on ixgbe On 16-02-09 06:24 AM, Fastabend, John R wrote: > On 2/4/2016 5:12 AM, Jamal Hadi Salim wrote: >> >> On 16-02-03 01:48 PM, Fastabend, John R wrote: >> >> Basically most hardware (or i should say driver implementations of >> mostly TCAMS) allow you to add exactly the same filter as many times >> as you want. They dont really look at what you want to filter on >> and then scream "conflict". IOW, you (user) are responsible for >> conflict resolution at the filter level. The driver sees this blob >> and requests for some index/key from the hardware then just adds it. >> You can then use this key/index to delete/replace etc. >> This is what i meant by "append" mode. >> However if a classifier implementation cares about filter ambiguity >> resolution, then priorities are used. We need to worry about the >> bigger picture. >> > > Sure in other classifiers its used but its not needed in the set I > planned to added it later. > If you leave it open for some other hardware to use we should be fine. >> >>> For this series using cls_u32 the handle gives you everything you need >>> to put entries in the right table and row. Namely the ht # and order # >>> from 'tc'. >> >> True - but with a caveat. There are only 2^12 max tables you can >> have for example and up to 2^12 filters per bucket etc. >> > > This is a software limitation as well right? If it hasn't showed up > as a limitation on the software side why would it be an issue here? > Do you have more than 2^12 tables on your devices? If so I guess we > can tack on another 32bits somewhere. > That handle is used as an "Address" to the 32 bit filter. Just beware of the semantics the handle has. It hasnt shown up as a software limitation because the defaults are good enough for most people. But if you ever want to install a million rules that can be looked up at a reasonable pps rate it will become very obvious quickly. I have a sample setup in the talk tommorow which shows such an example. >> I think you need to take the u32 address and map it to something in your >> hardware. But at the same time it is important to have the abstraction >> closely emulate your hardware. >> > > IMO the hardware/interface must preserve the same ordering of > filters/hash_Tables/etc. How it does that mapping should be > a driver concern and it can always abort if it fails. > Sure. >>> Also ran a few tests and can't see how priority works in u32 maybe you >>> can shed some light but as best I can tell it doesn't have any effect >>> on rule execution. >>> >> >> True. >> u32 doesnt care because it will give you a nodeid if you dont specify >> one. i.e conflict resolution is mapped to you not specifying exactly >> the same ht:bkt:nodeid more than once. And if you will let the >> kernel do it for you (as i am assumming you are saying your hardware >> will) then no need. > > Yep. Faithfully offloading u32 here not changing anything except > I do have to abort on some cases with the simpler devices. fm10k for > example can model hash nodes with divisors > 1. > I wonder if when we get to capabilities we can do this... >> > > My issue is we can map flower onto u32 that is fine and u32 onto > bpf. But we lose a lot of the power of each classifier when we > do this. flower for example is nice because of its simplicity > presumably this translates into faster updates, u32 is great because > we get full parse graph support and hash tables, ebpf is the biggest > beast of all and lets us load arbitrary functions into the device. > All are nice in their own right. > Did i send you my slides? ;-> cheers, jamal
Powered by blists - more mailing lists