* nfp bpf offload add/replace @ 2017-09-07 9:10 Jiri Pirko 2017-09-07 13:44 ` Jakub Kicinski 0 siblings, 1 reply; 4+ messages in thread From: Jiri Pirko @ 2017-09-07 9:10 UTC (permalink / raw) To: kubakici; +Cc: netdev, mlxsw Hi Kuba. I'm looking into cls_bpf code and nfp_net_bpf_offload function in your driver. Why do you need TC_CLSBPF_ADD? Seems like TC_CLSBPF_REPLACE should be enough. It would make the cls_bpf code easier. Note that other cls just have replace/destroy (u32 too, as drivers handle NEW/REPLACE in one switch-case - will patch this). Thanks! Jiri ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: nfp bpf offload add/replace 2017-09-07 9:10 nfp bpf offload add/replace Jiri Pirko @ 2017-09-07 13:44 ` Jakub Kicinski 2017-09-07 14:05 ` Jiri Pirko 0 siblings, 1 reply; 4+ messages in thread From: Jakub Kicinski @ 2017-09-07 13:44 UTC (permalink / raw) To: Jiri Pirko; +Cc: netdev, mlxsw, Daniel Borkmann, Simon Horman On Thu, 7 Sep 2017 11:10:33 +0200, Jiri Pirko wrote: > Hi Kuba. > > I'm looking into cls_bpf code and nfp_net_bpf_offload function in your > driver. Why do you need TC_CLSBPF_ADD? Seems like TC_CLSBPF_REPLACE > should be enough. It would make the cls_bpf code easier. > > Note that other cls just have replace/destroy (u32 too, as drivers > handle NEW/REPLACE in one switch-case - will patch this). Could we clarify what the REPLACE is actually supposed to do? :) In the flower code and the REPLACE looks a lot like ADD on the surface... If change is called it will invoke REPLACE with the new filter and then if there was an old filter, it will do DELETE. Is my understanding correct? If so I found this model of operation somehow confusing. Plus the management of flows may get slightly tricky if there is a possibility of "replacing" a flow with an identical one. Flower may make calls like these: add flower vlan_id 100 action ... # REPLACE vid 100 ... change ... flower vlan_id 100 action ... # REPLACE vid 100 ... # DELETE vid 100 ... Doesn't this force driver/HW to implement refcounting on the rules? On why I need the replace - BPF unlike other classifiers usually installs a single program, I think offloading multiple TC filters is questionable (people will use tailcalls instead most likely). I want to be able to implement atomic replace of that single program (i.e. not ADD followed by DELETE) because that simplifies the driver quite a bit. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: nfp bpf offload add/replace 2017-09-07 13:44 ` Jakub Kicinski @ 2017-09-07 14:05 ` Jiri Pirko 2017-09-07 16:52 ` Jakub Kicinski 0 siblings, 1 reply; 4+ messages in thread From: Jiri Pirko @ 2017-09-07 14:05 UTC (permalink / raw) To: Jakub Kicinski; +Cc: netdev, mlxsw, Daniel Borkmann, Simon Horman Thu, Sep 07, 2017 at 03:44:12PM CEST, kubakici@wp.pl wrote: >On Thu, 7 Sep 2017 11:10:33 +0200, Jiri Pirko wrote: >> Hi Kuba. >> >> I'm looking into cls_bpf code and nfp_net_bpf_offload function in your >> driver. Why do you need TC_CLSBPF_ADD? Seems like TC_CLSBPF_REPLACE >> should be enough. It would make the cls_bpf code easier. >> >> Note that other cls just have replace/destroy (u32 too, as drivers >> handle NEW/REPLACE in one switch-case - will patch this). > >Could we clarify what the REPLACE is actually supposed to do? :) > >In the flower code and the REPLACE looks a lot like ADD on the >surface... If change is called it will invoke REPLACE with the new >filter and then if there was an old filter, it will do DELETE. Is my >understanding correct? Yes, correct. > >If so I found this model of operation somehow confusing. Plus the >management of flows may get slightly tricky if there is a possibility of >"replacing" a flow with an identical one. Flower may make calls like >these: > >add flower vlan_id 100 action ... ># REPLACE vid 100 ... >change ... flower vlan_id 100 action ... ># REPLACE vid 100 ... ># DELETE vid 100 ... Yes, that is the flow. > >Doesn't this force driver/HW to implement refcounting on the rules? Why do you think so? There is a cookie that is passed from flower down and driver uses it to remove the entry. > >On why I need the replace - BPF unlike other classifiers usually >installs a single program, I think offloading multiple TC filters is >questionable (people will use tailcalls instead most likely). I want to >be able to implement atomic replace of that single program (i.e. not ADD >followed by DELETE) because that simplifies the driver quite a bit. Understood. So, looks like the REPLACE/DESTROY would be sufficient for bpf. ADD is not needed as it can be done by REPLACE-NULL, right? On the other hand, the rest of the cls, namely flower, u32 and matchall need ADD/DESTROY as they don't really do no replacing. Makes sense? ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: nfp bpf offload add/replace 2017-09-07 14:05 ` Jiri Pirko @ 2017-09-07 16:52 ` Jakub Kicinski 0 siblings, 0 replies; 4+ messages in thread From: Jakub Kicinski @ 2017-09-07 16:52 UTC (permalink / raw) To: Jiri Pirko; +Cc: netdev, mlxsw, Daniel Borkmann, Simon Horman On Thu, 7 Sep 2017 16:05:03 +0200, Jiri Pirko wrote: > Thu, Sep 07, 2017 at 03:44:12PM CEST, kubakici@wp.pl wrote: > >On Thu, 7 Sep 2017 11:10:33 +0200, Jiri Pirko wrote: > >> Hi Kuba. > >> > >> I'm looking into cls_bpf code and nfp_net_bpf_offload function in your > >> driver. Why do you need TC_CLSBPF_ADD? Seems like TC_CLSBPF_REPLACE > >> should be enough. It would make the cls_bpf code easier. > >> > >> Note that other cls just have replace/destroy (u32 too, as drivers > >> handle NEW/REPLACE in one switch-case - will patch this). > > > >Could we clarify what the REPLACE is actually supposed to do? :) > > > >In the flower code and the REPLACE looks a lot like ADD on the > >surface... If change is called it will invoke REPLACE with the new > >filter and then if there was an old filter, it will do DELETE. Is my > >understanding correct? > > Yes, correct. > > > > >If so I found this model of operation somehow confusing. Plus the > >management of flows may get slightly tricky if there is a possibility of > >"replacing" a flow with an identical one. Flower may make calls like > >these: > > > >add flower vlan_id 100 action ... > ># REPLACE vid 100 ... > >change ... flower vlan_id 100 action ... > ># REPLACE vid 100 ... > ># DELETE vid 100 ... > > Yes, that is the flow. > > > > >Doesn't this force driver/HW to implement refcounting on the rules? > > Why do you think so? There is a cookie that is passed from flower down > and driver uses it to remove the entry. Right, the key/mask combination doesn't have to be unique anyway... > >On why I need the replace - BPF unlike other classifiers usually > >installs a single program, I think offloading multiple TC filters is > >questionable (people will use tailcalls instead most likely). I want to > >be able to implement atomic replace of that single program (i.e. not ADD > >followed by DELETE) because that simplifies the driver quite a bit. > > Understood. So, looks like the REPLACE/DESTROY would be sufficient for > bpf. ADD is not needed as it can be done by REPLACE-NULL, right? Yes, or you could take it to the extreme ;) DESTROY == offload(old, NULL) ADD == offload(NULL, new) REPLACE == offload(obj, new) > On the other hand, the rest of the cls, namely flower, u32 and matchall > need ADD/DESTROY as they don't really do no replacing. > > Makes sense? Ack, if you're unifying things, I don't mind how things are muxed as long as atomic replace is possible. FWIW cls_bpf doesn't pass old prog in REPLACE right now, but I have patch to add it anyway since it simplifies the driver when maps are involved. I should probably stop looking at the .command completely, just rely on new/old programs being populated. ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2017-09-07 16:52 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2017-09-07 9:10 nfp bpf offload add/replace Jiri Pirko 2017-09-07 13:44 ` Jakub Kicinski 2017-09-07 14:05 ` Jiri Pirko 2017-09-07 16:52 ` Jakub Kicinski
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).