On Wed, Feb 22, 2017 at 01:47:17PM -0800, Tom Herbert wrote: > On Wed, Feb 22, 2017 at 1:29 PM, Or Gerlitz <gerlitz...@gmail.com> wrote: > > On Thu, Feb 16, 2017 at 11:58 PM, Andreas Schultz <aschu...@tpip.net> wrote: > >> Hi Or, > >> ----- On Feb 16, 2017, at 3:59 PM, Or Gerlitz ogerl...@mellanox.com wrote: > >> > >>> Generate the source udp header according to the flow represented by > >>> the packet we are encapsulating, as done for other udp tunnels. This > >>> helps on the receiver side to apply RSS spreading. > >> > >> This might work for GTPv0-U, However, for GTPv1-U this could interfere > >> with error handling in the user space control process when the UDP port > >> extension header is used in error indications. > > > > > > in the document you posted there's this quote "The source IP and port > > have no meaning and can change at any time" -- I assume it refers to > > v0? can we identify in the kernel code that we're on v0 and have the > > patch come into play? > > > >> 3GPP TS 29.281 Rel 13, section 5.2.2.1 defines the UDP port extension and > >> section 7.3.1 says that the UDP source port extension can be used to > >> mitigate DOS attacks. This would IMHO imply that the user space control > >> process needs to know the TEID to UDP source port mapping. > > > >> The other question is, on what is this actually hashing. When I understand > >> the code correctly, this will hash on the source/destination of the orignal > >> flow. I would expect that a SGSN/SGW/eNodeB would like the keep flow > >> processing on a per TEID base, so the port hashing should be base on the > >> TEID. > > > > is it possible for packets belonging to the same TCP session or UDP > > "pseudo session" (given pair of src/dst ip/port) to be encapsulated > > using different TEID? > > > > hashing on the TEID imposes a harder requirement on the NIC HW vs. > > just UDP based RSS. > > This shouldn't be taken as a HW requirement and it's unlikely we'd add > explicit GTP support in flow_dissector. If we can't get entropy in the > UDP source port then IPv6 flow label is a potential alternative (so > that should be supported in NICs for RSS).
According to specs, section 4.4.2.3 Encapsulated T-PDU, TS 29.281. "The UDP Source Port is a locally allocated port number at the sending GTP-U entity." Older specs that refer to GTP-U such as TS 09.60 and TS 29.060 also state the same. So Or patch looks fine to me.
