On Fri, Oct 18, 2013 at 5:58 PM, Romain Lenglet <rleng...@vmware.com> wrote: > ----- 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?
I guess it's not entirely clear to me at this point why it's important to record the UDP source port. Can you explain? _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
