All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Hemminger <shemminger@vyatta.com>
To: Jesse Gross <jesse@nicira.com>
Cc: davem@davemloft.net, netdev@vger.kernel.org
Subject: Re: [PATCH 3/3] vxlan: virtual extensible lan
Date: Wed, 3 Oct 2012 21:02:20 -0700	[thread overview]
Message-ID: <20121003210220.5e74aa5d@nehalam.linuxnetplumber.net> (raw)
In-Reply-To: <CAEP_g=9Y3MmsABQJyi508FEgs4635tnaVqk4Ncwbpm41bLskhg@mail.gmail.com>

On Wed, 3 Oct 2012 18:54:46 -0700
Jesse Gross <jesse@nicira.com> wrote:

> On Mon, Oct 1, 2012 at 3:32 PM, Stephen Hemminger <shemminger@vyatta.com> wrote:
> > --- /dev/null   1970-01-01 00:00:00.000000000 +0000
> > +++ b/drivers/net/vxlan.c       2012-10-01 15:08:38.024499080 -0700
> > +/* Transmit local packets over Vxlan
> > + *
> > + * Outer IP header inherits ECN and DF from inner header.
> > + * Outer UDP destination is the VXLAN assigned port.
> > + *           source port is based on hash of flow if available
> > + *                       otherwise use a random value
> > + */
> > +static netdev_tx_t vxlan_xmit(struct sk_buff *skb, struct net_device *dev)
> [...]
> > +       hash = skb_get_rxhash(skb);
> [...]
> > +       uh->dest = htons(vxlan_port);
> > +       uh->source = hash ? :random32();
> 
> I think this may lead to packet reordering in some cases.  If the
> protocol is unknown then it may still represent part of a flow and
> random source ports could lead to taking different paths.
> 
> Also, does it make sense to restrict the range of ports to, say, the
> upper half of the range?

Since port is always a pair, there is no need to restrict range, unless
there was a broken firewall in the way. One bug there is that random32()
can return 0 which is not a valid port number.  A better fallback
would be a hash of the MAC header.

  reply	other threads:[~2012-10-04  4:03 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20121001223232.566037595@vyatta.com>
2012-10-01 22:32 ` [PATCH 1/3] netlink: add attributes to fdb interface Stephen Hemminger
2012-10-01 22:40   ` David Miller
2012-10-01 22:32 ` [PATCH 2/3] igmp: export symbol ip_mc_leave_group Stephen Hemminger
2012-10-01 22:40   ` David Miller
2012-10-01 22:32 ` [PATCH 3/3] vxlan: virtual extensible lan Stephen Hemminger
2012-10-01 22:40   ` David Miller
2012-10-04  1:54   ` Jesse Gross
2012-10-04  4:02     ` Stephen Hemminger [this message]
2012-10-04  6:34       ` Eric Dumazet
2012-10-04 15:12         ` Stephen Hemminger
2012-10-04 16:25           ` Jesse Gross
2012-10-04  4:39     ` [RFC] vxlan: use ether header as fallback hash Stephen Hemminger
2012-10-04  4:57       ` Eric Dumazet
2012-10-04  5:06         ` Stephen Hemminger
2012-10-04 16:27       ` Jesse Gross
2012-10-04 16:43         ` Stephen Hemminger
2012-10-04 17:06           ` Jesse Gross
2012-10-04 17:07           ` Eric Dumazet

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20121003210220.5e74aa5d@nehalam.linuxnetplumber.net \
    --to=shemminger@vyatta.com \
    --cc=davem@davemloft.net \
    --cc=jesse@nicira.com \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.