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
| ||
|
Message-ID: <54F078A1.6030008@mojatatu.com> Date: Fri, 27 Feb 2015 09:01:05 -0500 From: Jamal Hadi Salim <jhs@...atatu.com> To: John Fastabend <john.r.fastabend@...el.com>, Florian Fainelli <f.fainelli@...il.com>, Jiri Pirko <jiri@...nulli.us>, netdev@...r.kernel.org CC: davem@...emloft.net, nhorman@...driver.com, andy@...yhouse.net, tgraf@...g.ch, dborkman@...hat.com, ogerlitz@...lanox.com, jesse@...ira.com, jpettit@...ira.com, joestringer@...ira.com, sfeldma@...il.com, roopa@...ulusnetworks.com, linville@...driver.com, simon.horman@...ronome.com, shrijeet@...il.com, gospo@...ulusnetworks.com, bcrl@...ck.org Subject: Driver level interface WAS(Re: Flows! Offload them. On 02/26/15 15:58, John Fastabend wrote: > My thinking on this is to use the FlowAPI ndo_ops as the bottom layer. > What I would much prefer (having to actually write drivers) is that > we have one API to the driver and tc, nft, whatever map onto that API. > > Then my driver implements a ndo_set_flow op and a ndo_del_flow op. What > I'm working on now is the map from tc onto the flow API I'm hoping this > sounds like a good idea to folks. > In the name of starting simple (just like we did with L2 and upcoming L3), I think the idea is sane. If a driver exposes a "5 tuple classifier" - that is a hell lot easier to deal with from a policy perspective. I dont need to know that when you tell me "I can handle 10K rules" that somehow in your clever magic (or "IPR" as some people like to claim it) you managed to use only 20K Tcam entries or 5K compressed Sram entries. That becomes your problem as a driver. IOW: the driver should be in charge of the hardware resource management. In my experience, it is a nightmare having to deal with a situation where i just installed a rule and now in some bizare twisted plot i just lost or gained 100 entries. So a strategy for a driver interface depending on underlying hardware is the right thing to do; in such a case i think tcam based hardware offload would be fine fit for your API. There may be other strategies to deal with different hardware - however, as long as we are consistent we should be able to replace things when necessary. Likewise i find the simple "set" thing to be a usability challenge (we have done it in tc with pedit, but why the fsck would i use that to change an ip address? could easily have done the nat action with it, but there is a point where usability becomes paramount) > Neil, suggested we might need a reservation concept where tc can reserve > some space in a TCAM, similarly nft can reserve some space. Also I have > applications in user space that want to reserve some space to offload > their specific data structures. This idea seems like a good one to me. > I think this is treading into "advanced territory" as well. Who gets to decide on what app uses what is reserved? From a kernel perspective: I can understand conceptually we could label the entries to an owner. We already do this with routing (look for field "protocol" in rtm). However, theres a big can of worms that will need to be opened - what happens when the owner of such reservation dies etc? is tc/nftables allowed to add rules or it is based on user id? You need to deal not just with such issues but authentication, authorization etc of individual apps - such richness belongs to user space imo. cheers, jamal -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists