Yes. I separated this into 2 parts because the first one (datapath changes) is just to bring the in-tree module into line with netdev net-next. The second part contains the user-space changes and unit tests. There are some comments marked with "XXX" to invite close scrutiny.
If this approach is accepted then I can follow up with further enhancements to report on QinQ, NAT, 64-bit tunnel keys, and to improve the monitoring of Geneve and STT. That should all be pretty straightforward now. No further changes to datapath required. Neil ------ Neil McKee InMon Corp. http://www.inmon.com On Mon, Jun 22, 2015 at 10:38 AM, Jesse Gross <je...@nicira.com> wrote: > On Mon, Jun 22, 2015 at 10:11 AM, Ben Pfaff <b...@nicira.com> wrote: > > On Thu, Jun 11, 2015 at 09:43:58AM -0700, Neil McKee wrote: > >> If new optional attribute OVS_USERSPACE_ATTR_ACTIONS is added to an > >> OVS_ACTION_ATTR_USERSPACE action, then include the datapath actions > >> in the upcall. > >> > >> This Directly associates the sampled packet with the path it takes > >> through the virtual switch. Path information currently includes > mangling, > >> encapsulation and decapsulation actions for tunneling protocols GRE, > >> VXLAN, Geneve, MPLS and QinQ, but this extension requires no further > >> changes to accommodate datapath actions that may be added in the > >> future. > >> > >> Adding path information enhances visibility into complex virtual > >> networks. > >> > >> Signed-off-by: Neil McKee <neil.mc...@inmon.com> > > > > I think that one reason that this might be having some trouble getting > > reviews is because it's against the datapath directory. For some time > > now, the path for changes to the Linux datapath is to first post them to > > the netdev mailing list and get them committed to upstream Linux, then > > to port equivalent changes to the Open vSwitch in-tree module. (I don't > > follow netdev; maybe you've already done that.) > > The kernel part was already applied to upstream Linux. This is the > backport (I assume, although I haven't checked, that it is the same). > I think at this point it mostly needs a review of the userspace > portions. > _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev