Message-ID: <OF67C23F4E.05FEE247-ON85257B3C.0045D89E-85257B3C.00498794@us.ibm.com>
Date:	Thu, 28 Mar 2013 09:23:13 -0400
From:	David Stevens <dlstevens@...ibm.com>
To:	Alexander Duyck <alexander.h.duyck@...el.com>
Cc:	davem@...emloft.net, jeffrey.t.kirsher@...el.com, jesse@...ira.com,
	joseph.gasparakis@...el.com, netdev@...r.kernel.org,
	netdev-owner@...r.kernel.org, pshelar@...ira.com,
	shemminger@...tta.com,
	Stephen Hemminger <stephen@...workplumber.org>
Subject: Re: [PATCH net-next] vxlan: Provide means for obtaining port information

> From: Alexander Duyck <alexander.h.duyck@...el.com>
 
> Yes this will break if we ended up supporting a different port per
> VXLAN.  The problem is a port per VXLAN is going to be much more
> difficult to support for any sort of hardware offload as well.  What we
> end up having to do is add a significant number of filters just to
> identify all of the possible ports that may be used. 

        I assume this would only be an issue if you actually have lots
of ports. If you're using only one, or a couple, which I'd expect to
be the common case, your filtering needs should be the same, right?

> In addition it
> will mean having to add some sort of notifier as I mentioned in the
> patch description since we will have VXLANs going into and out of
> existence, each one with their own port number..

        I don't know the context in which you're planning to call this,
but regardless of the port or ports in use by VXLAN, the devices will
come and go and the module may be unloaded, so I don't see how what
you've said here applies to one case and not the other.


> This was essentially a "good enough for now" fix to address the fact
> that I needed the port number for offload testing, but I will sit back
> and wait for the port per VXLAN stuff to be pushed in before I take any
> steps to try to sort that out.

        What I was suggesting "for now" is that you create an interface
that need not change to support multiple ports. For example:

int vxlan_get_ports(struct net_device *dev, int *ports, int portcount)
{
        if (portcount <= 0 || vxlan_port == 0)
                return 0;
        if (ports)
                ports[0] = vxlan_port;
        return 1;
}

The return value would be the count of ports in use, and we'd fill up to a 
maximum
of portcount in the "ports" array. If you don't have a "dev" you're 
interested in,
pass it as NULL and in the future this code would match dev only if it is 
non-NULL;
otherwise it would go through the vxlan device list adding ports not in 
the list to it.

And for the right functionality now, change the VXLAN driver to leave 
vxlan_port
zero until a device is instantiated, so you can detect no ports at the 
moment,
and set it to zero again when the last one is deleted.

You need a mechanism to delete your filters if there are no VXLAN devices,
whether or not multiple ports are supported, because "0" is a legal count
now too. If I haven't created any vxlan devices, I can use port 8472 for
something else and your loading of the vxlan driver as a side-effect of
checking the port shouldn't prevent that. That's especially true in a
distro release where, while I might be able to change the port, I'd have
to burn one regardless if your driver were loaded, if it can't go without
a binding when there are no vxlan devices on the system.

                                                                +-DLS

--
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