On Tue, Nov 13, 2012 at 6:39 PM, Kyle Mestery (kmestery) <[email protected] > wrote:
> On Nov 13, 2012, at 6:17 PM, Jesse Gross <[email protected]> wrote: > > > > On Tue, Nov 13, 2012 at 2:19 PM, Kyle Mestery <[email protected]> > wrote: > > Add support for VXLAN tunnels to Open vSwitch. Add support > > for setting the destination UDP port on a per-port basis. > > This is done by adding a "dst_port" parameter to the port > > configuration. This is only applicable currently to VXLAN > > tunnels. > > > > Specifically, I'd like some comments on the hashing for the source > > port selection. Currently it's using the flow-hash to generate a > > source port. I think what we could replace it with is this: > > > > return (__force __be16)skb_get_rxhash(skb) | htons(32768); > > > > I haven't looked at the whole thing yet but as far as this specific > point, here's the way that it is done upstream: > > > > /* Compute source port for outgoing packet > > * first choice to use L4 flow hash since it will spread > > * better and maybe available from hardware > > * secondary choice is to use jhash on the Ethernet header > > */ > > static u16 vxlan_src_port(const struct vxlan_dev *vxlan, struct sk_buff > *skb) > > { > > unsigned int range = (vxlan->port_max - vxlan->port_min) + 1; > > u32 hash; > > > > hash = skb_get_rxhash(skb); > > if (!hash) > > hash = jhash(skb->data, 2 * ETH_ALEN, > > (__force u32) skb->protocol); > > > > return (((u64) hash * range) >> 32) + vxlan->port_min; > > } > > > > where port_min and max are determined using inet_get_local_port_range(). > > Thanks Jesse. I'll reformulate the patch with this change and send it back > out tomorrow. > > Also, I have not yet tested the VXLAN+IPSEC combination yet, and I'm > wondering what your thoughts are on supporting that as well. I'll try to > test that part out tomorrow as well. Comments on the rest are welcome as > well, I'll prioritize addressing these the rest of the week For the time being, I don't have a strong preference on IPsec. We're going to have to change the way that it is implemented as we switch over to flow based tunneling and the new way won't require any explicit support in the tunneling implementation. If you want to pull it out now so that you don't have to test it that's fine since unencrypted VXLAN is still a complete feature by itself. Conversely, if you want to leave it in since it's already there, that's fine too.
_______________________________________________ dev mailing list [email protected] http://openvswitch.org/mailman/listinfo/dev
