Re: [nvo3] One comment for draft-dt-nvo3-encap-01

On Thu, May 25, 2017 at 12:58 PM, Lizhong Jin wrote: > Hi Tom, > > Sorry for the late reply, I finally get the time to read your document. Yes, > you are right for the Linux RFS implementation, where RFS is indexed with > hash value. But for the NIC hardware accelerated RFS,

Re: [nvo3] One comment for draft-dt-nvo3-encap-01

Hi Tom, Sorry for the late reply, I finally get the time to read your document. Yes, you are right for the Linux RFS implementation, where RFS is indexed with hash value. But for the NIC hardware accelerated RFS, it is not the case. The flow is indexed not by hash value, but 5/4/3/2-tuple exact

Re: [nvo3] One comment for draft-dt-nvo3-encap-01

On 5/15/2017 12:53 PM, Tom Herbert wrote: > I'm pretty sure the latest versions of all the major OSes are setting > the flow label If that hasn't happened, I agree it's likely to happen soon... > so hopefully the motivation to do DPI will go away. DPI isn't just based on flow management; it's

Re: [nvo3] One comment for draft-dt-nvo3-encap-01

On Mon, May 15, 2017 at 12:02 PM, Joe Touch wrote: > > > On 5/6/2017 8:24 AM, Tom Herbert wrote: >> Using the entropy in the UDP port number works perfectly well to get >> ECMP or RSS for any UDP encapsulation including Geneve, VXLAN, GUE, >> etc. If the UDP port number weren't

Re: [nvo3] One comment for draft-dt-nvo3-encap-01

On 5/6/2017 8:24 AM, Tom Herbert wrote: > Using the entropy in the UDP port number works perfectly well to get > ECMP or RSS for any UDP encapsulation including Geneve, VXLAN, GUE, > etc. If the UDP port number weren't good enough then the IPv6 flow > label can be used (and that works for

Re: [nvo3] One comment for draft-dt-nvo3-encap-01

On Sat, May 6, 2017 at 9:05 AM, Greg Mirsky wrote: > Hi Tom and Lizhong, > I the strongest terms agree with your view that intermediate nodes should > not use DPI to do flow steering. Decisions should be based on information > expressed in the transport layer, not derived

Re: [nvo3] One comment for draft-dt-nvo3-encap-01

On Sat, May 6, 2017 at 9:15 AM, lizho.jin wrote: > Tom, see inline below. > > > Regards > Lizhong > > On 05/6/2017 23:45，Tom Herbert wrote： > > On Sat, May 6, 2017 at 8:37 AM, lizho.jin wrote: >> I am not referring RSS, but RFS with

Re: [nvo3] One comment for draft-dt-nvo3-encap-01

Tom, see inline below. RegardsLizhong On 05/6/2017 23:45，Tom Herbert wrote： On Sat, May 6, 2017 at 8:37 AM, lizho.jin  wrote: > I am not referring RSS, but RFS 

Re: [nvo3] One comment for draft-dt-nvo3-encap-01

Hi Tom and Lizhong, I the strongest terms agree with your view that intermediate nodes should not use DPI to do flow steering. Decisions should be based on information expressed in the transport layer, not derived from the payload. Otherwise, active OAM cannot be viewed as in-band thus making

Re: [nvo3] One comment for draft-dt-nvo3-encap-01

On Sat, May 6, 2017 at 8:37 AM, lizho.jin wrote: > I am not referring RSS, but RFS with HW acceleration. What I > > proposed is to use hash value instead of 5-tuple to do flow steering. > RFS works as is also. The only requirement for RFS is that the hash is reasonably

Re: [nvo3] One comment for draft-dt-nvo3-encap-01

I am not referring RSS, but RFS with HW acceleration. What I proposed is to use hash value instead of 5-tuple to do flow steering.Sorry for the misunderstanding. RegardsLizhong On 05/6/2017 23:24，Tom

Re: [nvo3] One comment for draft-dt-nvo3-encap-01

On Fri, May 5, 2017 at 6:39 PM, lizho.jin wrote: > Tom, thanks for the reply, see inline below. > > Regards > Lizhong > > On 05/6/2017 00:14，Tom Herbert wrote： > > [Lizhong] Total option length will not solve the parser buffer issue. > The parser buffer

Re: [nvo3] One comment for draft-dt-nvo3-encap-01

Tom, thanks for the reply, see inline below. RegardsLizhong On 05/6/2017 00:14，Tom Herbert wrote： [Lizhong] Total option length will not solve the parser buffer issue. The parser 

Re: [nvo3] One comment for draft-dt-nvo3-encap-01

[Lizhong] Total option length will not solve the parser buffer issue. The parser buffer is located before parser, and for Geneve, implement 512Byte is the only way since the longest of Geneve header is 260Bytes. At least in some implementations as I know, hardware will firstly receive enough

[nvo3] One comment for draft-dt-nvo3-encap-01

Hi authors,One comment for the section 7 "Design team recommendations":2. Geneve has the total options length that allow skipping over the options for NIC offload operations, and will allow transit devices to view flow information in the inner payload.[Lizhong] Total option