----- Original Message ----- > From: "Jesse Gross" <je...@nicira.com> > To: "Romain Lenglet" <rleng...@vmware.com> > Cc: "Neil Mckee" <neil.mc...@inmon.com>, dev@openvswitch.org > Sent: Friday, October 18, 2013 5:50:05 PM > Subject: Re: [ovs-dev] [PATCH] sFlow export: include standard tunnel > structures (for GRE, VXLAN etc.) > > On Fri, Oct 18, 2013 at 5:43 PM, Romain Lenglet <rleng...@vmware.com> wrote: > > ----- Original Message ----- > >> From: "Romain Lenglet" <rleng...@vmware.com> > >> To: "Neil Mckee" <neil.mc...@inmon.com> > >> Cc: dev@openvswitch.org > >> Sent: Wednesday, October 9, 2013 10:30:17 AM > >> Subject: Re: [ovs-dev] [PATCH] sFlow export: include standard tunnel > >> structures (for GRE, VXLAN etc.) > >> > >> On Oct 8, 2013, at 10:09 PM, Neil Mckee <neil.mc...@inmon.com> wrote: > >> > + /* Indicate 0==unknown for the src_port. It may be set to a random > >> > + number on a flow-by-flow basis to increase entropy for ECMP > >> > fabrics. > >> > + The assumption being made here is that it is not so important to > >> > + report this. At least not important enough to justify the > >> > effort > >> > + of making it accessible here. */ > >> > >> Exporting the source UDP source port is essential. > >> You also have to export the tunnel key: GRE key (32- or 64-bit), VNI > >> (24-bit), etc. > >> I don't see how this feature could be useful without the UDP source port > >> and > >> tunnel key. > > > > I thought more about this. Exporting the source UDP port is really > > important. Since the source port is calculated in the tunnel port at > > egress during encapsulation and is lost at ingress during decapsulation, > > and the sampling here is done before encapsulation or after decapsulation, > > the easiest way I can imagine to determine the source port is to redo the > > hashing here. This would require factorizing the hashing code into a > > function that can be used in userspace in this code. > > I don't think that it's really viable to regenerate the hash used to > compute the source port. In the best case, we are the ones generating > it but the kernel hash function might change or the hash might come > from the NIC. In the worst case, when we receive a packet the hash > could have been generated by a non-OVS device with an unknown hash > algorithm >
Yes, agreed, that's a problem. The only other alternative I can imagine to get the source UDP port is to do the sampling in the port (esp. in the tunnel port) in the datapath. This would be quite intrusive and complicated, as it would require the ports to do sampling and upcalls. I'd prefer to avoid that. Do you see any other alternative? -- Romain Lenglet _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
