On 09.06.2016 18:14, Alexander Duyck wrote: > On Thu, Jun 9, 2016 at 3:57 AM, Hannes Frederic Sowa <han...@redhat.com> > wrote: >> On 09.06.2016 04:33, Alexander Duyck wrote: >>> On Wed, Jun 8, 2016 at 3:20 PM, Hannes Frederic Sowa <han...@redhat.com> >>> wrote: >>>> The remaining problem regarding offloads would be, that we by default >>>> get into the situation that without the special offloading rule the >>>> vxlan stream will only be processed on one single core, as we tell >>>> network cards not to hash the udp ports into rxhash, which hurts a lot >>>> in case of vxlan, where we bias the flow identification on the source >>>> port without offloading available. >>> >>> Most NICs offer the option of hashing on UDP ports. In the case of >>> the Intel NICs I know you can turn on UDP port hashing by using >>> ethtool and setting UDP hasing to be enabled via "ethtool -N <iface> >>> udp4 sdfn". You can do the same thing using "udp6" for IPv6 based >>> tunnels. That is usually enough to cover all the bases and the fact >>> is not too many people are passing fragmented UDP traffic and as long >>> as that is the case enabling UDP hashing isn't too big of a deal. >> >> True, I am wondering how safe it is given the reordering effects it has >> on UDP and thus other non vxlan management protocols on the hypervisors. >> >> At that time, when UDP port hashing was disabled, the message was pretty >> clear by upstream and I don't think for the default case anything should >> change here. >> >> Are the port hashing features also global or tweakable per VF? > > That one depends on the device. I think in the case of some of the > newer NICs the VFs support separate RSS tables. The ones that have > shared RSS tables typically share how they compute the hashes. So for > example with igb and ixgbe you get a shared has computation where the > PF will impact the VFs. One easy fix for the reordering though is to > simply disable RSS on the VFs which in many cases will likely occur > anyway unless the guest has multiple VCPUs.
Sounds like a bad limitation. I assume multiple VCPUs are used in VMs (I even do that). Hypothetically for IPv4 vxlan in a datacenter, can't we randomize the IPv4 address bits and isolate it properly just as the transport protocol for vxlan (e.g. the lower 2 bytes)? But that is becoming ugly... We break ICMP already with UDP source port randomization. > In the case of ixgbe it just occurred to me that there is also an > option of applying flow director rules and it would be possible to > just add a rule for each CPU so that you split the UDP source port > space up based on something like the lower 4 bits assuming 16 queues > for instance. The deployment of that based on the used hardware will also be terrible. Bye, Hannes _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
