Thu, Jul 16, 2015 at 09:09:39AM CEST, sfel...@gmail.com wrote: >On Wed, Jul 15, 2015 at 11:58 PM, Jiri Pirko <j...@resnulli.us> wrote: >> Thu, Jul 16, 2015 at 08:40:31AM CEST, sfel...@gmail.com wrote: >>>On Wed, Jul 15, 2015 at 6:39 PM, Simon Horman >>><simon.hor...@netronome.com> wrote: >>>> Teach rocker to forward packets to CPU when a port is joined to Open >>>> vSwitch. >>>> There is scope to later refine what is passed up as per Open vSwitch flows >>>> on a port. >>>> >>>> This does not change the behaviour of rocker ports that are >>>> not joined to Open vSwitch. >>>> >>>> Signed-off-by: Simon Horman <simon.hor...@netronome.com> >>> >>>Acked-by: Scott Feldman <sfel...@gmail.com> >>> >>>Now, OVS flows on a port. Strange enough, that was the first RFC >>>implementation for switchdev/rocker where we hooked into ovs-kernel >>>module and programmed flows into hw. We pulled all of that code >>>because, IIRC, the ovs folks didn't want us hooking into the kernel >>>module directly. We dropped the ovs hooks and focused on hooking >>>kernel's L2/L3. The device (rocker) didn't really change: OF-DPA >>>pipeline was used for both. Might be interesting to try hooking it >>>again. >> >> >> I think that now we have an infrastructure prepared for that. I mean, >> what we need to do is to introduce another generic switchdev object >> called "ntupleflow" and hook-up again into ovs datapath and cls_flower >> and insert/remove the object from those codes. Should be pretty easy to do. > >That sounds right. Is the ovs datapath hooking still happening in the >ovs-kernel module? Remind me again, what was the objection the last >time we tried that?
Yep, we need to hook there. Otherwise it won't be transparent. Last time the objection was that this would be ovs specific. But that is passed today. We have switchdev infra with objects, we have cls_flower which would use the same object. I say let's do this now. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
