[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1369942387.2414.24.camel@bwh-desktop.uk.level5networks.com>
Date: Thu, 30 May 2013 20:33:07 +0100
From: Ben Hutchings <bhutchings@...arflare.com>
To: Stephen Hemminger <stephen@...workplumber.org>
CC: David Stevens <dlstevens@...ibm.com>, <netdev@...r.kernel.org>
Subject: Re: RFC - VXLAN port range facility
On Thu, 2013-05-30 at 09:41 -0700, Stephen Hemminger wrote:
> On Thu, 30 May 2013 08:40:56 -0400
> David Stevens <dlstevens@...ibm.com> wrote:
[...]
> > I think a port ranges may be useful in the context of a small number (say
> > 10)
> > of ports that you are actually bound to, so then as part of multi-port
> > binding
> > support. But then a default range of 32K-61K is too large. It then, at
> > least,
> > has the potential to manage ICMP errors triggered by VXLAN.
>
> Port ranges are critical to retaining scaling in multi-path infrastructure.
> Otherwise all traffic will arrive on a single queue in NIC.
[...]
If you include UDP port numbers in the flow hash, a UDP flow with a
mixture of fragmented and unfragmented datagrams is likely to be split
between two queues. Most multiqueue NICs follow the Microsoft RSS spec
which says to include the port numbers in the flow hash for TCP only.
Some hardware and drivers provide the option to override the hashing
behaviour for UDP or to steer by port number, but perhaps it would be
more portable to support the use of a range of IP addresses?
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists