[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CALnjE+pDezZ26=1kPOPAC4GNuaarsgFnp16NeT=JM=Ag__f84Q@mail.gmail.com>
Date: Tue, 26 Mar 2013 16:57:12 -0700
From: Pravin Shelar <pshelar@...ira.com>
To: David Stevens <dlstevens@...ibm.com>
Cc: davem@...emloft.net, jesse@...ira.com, netdev@...r.kernel.org,
netdev-owner@...r.kernel.org,
Stephen Hemminger <stephen@...workplumber.org>
Subject: Re: [PATCH v2 net-next] VXLAN: Precompute vin for VXLAN header.
On Tue, Mar 26, 2013 at 3:44 PM, David Stevens <dlstevens@...ibm.com> wrote:
> netdev-owner@...r.kernel.org wrote on 03/26/2013 05:33:14 PM:
>
>>
>> Compute VXLAN vin at time of device create so that there is no need
>> to translate it on packet send and receive.
>> This patch do not change userspace interface.
>
> The name of the field is "VNI" (Virtual Network Identifier), not
> "vin")
>
>> -static inline struct hlist_head *vni_head(struct net *net, u32 id)
>> +static u32 vni_to_vid(__be32 vni)
>> +{
>> + return ntohl(vni) >> 8;
>> +}
>> +
>> +static __be32 vid_to_vni(u32 id)
>> +{
>> + return htonl(id << 8);
>> +}
>
> What's a "vid"? I know what you're trying to do here, but like
> "vin",
> it is not proper VXLAN terminology. I don't think these need to be
> functions at all, but rather simply in-line code. I think renaming
> this as a "vid" just obscures what it is.
> Changing it to a bitfield of the right size and place might
> be more proper, but probably not worth the complexity.
> But if you want them to be functions (or, I'd prefer macros),
> I'd suggest something like hton_vni() and ntoh_vni() -- transforming
> between the host and packet (network) formats -- and adding "inline".
>
>> +
>> +static inline struct hlist_head *vni_head(struct net *net, __be32 id)
>> {
>> struct vxlan_net *vn = net_generic(net, vxlan_net_id);
>>
>> - return &vn->vni_list[hash_32(id, VNI_HASH_BITS)];
>> + return &vn->vni_list[hash_32((__force u32)id, VNI_HASH_BITS)];
>> }
>>
>> /* Look up VNI in a per net namespace table */
>> -static struct vxlan_dev *vxlan_find_vni(struct net *net, u32 id)
>> +static struct vxlan_dev *vxlan_find_vni(struct net *net, __be32 id)
>> {
>> struct vxlan_dev *vxlan;
>>
>> @@ -195,7 +205,7 @@ static int vxlan_fdb_info(struct sk_buff *skb,
>> struct vxlan_dev *vxlan,
>> nla_put_be16(skb, NDA_PORT, rdst->remote_port))
>> goto nla_put_failure;
>> if (rdst->remote_vni != vxlan->vni &&
>> - nla_put_be32(skb, NDA_VNI, rdst->remote_vni))
>> + nla_put_be32(skb, NDA_VNI, vni_to_vid(rdst->remote_vni)))
>> goto nla_put_failure;
>> if (rdst->remote_ifindex &&
>> nla_put_u32(skb, NDA_IFINDEX, rdst->remote_ifindex))
>> @@ -261,7 +271,7 @@ static void vxlan_ip_miss(struct net_device
>> *dev, __be32 ipa)
>> memset(&f, 0, sizeof f);
>> f.state = NUD_STALE;
>> f.remote.remote_ip = ipa; /* goes to NDA_DST */
>> - f.remote.remote_vni = VXLAN_N_VID;
>> + f.remote.remote_vni = vid_to_vni(VXLAN_N_VID);
>
> This is not correct -- VXLAN_N_VID is an invalid VNI with
> value 1<<24. Applying vid_to_vni() makes it 1<<32 (==0 since it's 32
> bits wide). To do the same thing correctly here, you'd either need to
> make it 64 bits, or now set a bit in the low-order byte and then have
> that transform to 1<<24 in host representation.
>
> So, perhaps [again, ought to have a name changes], so:
>
> static u32 ntoh_vni(__be32 vni)
> {
> if (vni & 0xff)
> return VXLAN_N_VID;
> return ntohl(vni) >> 8;
> }
>
> static __be32 hton_vni(u32 id)
> {
> if (vni >= VXLAN_N_VID)
> return 1;
> return htonl(id << 8);
> }
>
> Or, instead of "1", you could use a define of VXLAN_N_VID_NET or
> some such.
> Of course, that'll work internally only as long as the reserved
> bits in the packet are 0; if they're used for something else, you need
> to mask them before calling this.
>
> All in all, I'm not sure it's worth the trouble for a few
> byte-swaps.
>
right, there is no simple solution to avoid byte swaps here, I will
drop this patch for now.
--
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