On Wed, Aug 12, 2015 at 4:08 PM, Pravin Shelar <pshe...@nicira.com> wrote:
> On Wed, Aug 12, 2015 at 1:53 PM, Jesse Gross <je...@nicira.com> wrote:
>> On Tue, Aug 11, 2015 at 10:17 PM, Pravin B Shelar <pshe...@nicira.com> wrote:
>>> diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c
>>> index 5e9bab8..a463383 100644
>>> --- a/drivers/net/geneve.c
>>> +++ b/drivers/net/geneve.c
>>> +static struct geneve_dev *geneve_lookup(struct geneve_net *gn,
>>> + struct iphdr *iph,
>>> + struct genevehdr *gnvh)
>>> {
>>> - struct genevehdr *gnvh = geneve_hdr(skb);
>>> - struct geneve_dev *dummy, *geneve = NULL;
>>> - struct geneve_net *gn;
>>> - struct iphdr *iph = NULL;
>>> - struct pcpu_sw_netstats *stats;
>>> struct hlist_head *vni_list_head;
>>> - int err = 0;
>>> + struct geneve_dev *geneve;
>>> __u32 hash;
>>>
>>> - iph = ip_hdr(skb); /* Still outer IP header... */
>>> -
>>> - gn = gs->rcv_data;
>>> -
>>> /* Find the device for this VNI */
>>> hash = geneve_net_vni_hash(gnvh->vni);
>>> vni_list_head = &gn->vni_list[hash];
>>> - hlist_for_each_entry_rcu(dummy, vni_list_head, hlist) {
>>> - if (!memcmp(gnvh->vni, dummy->vni, sizeof(dummy->vni)) &&
>>> - iph->saddr == dummy->remote.sin_addr.s_addr) {
>>> - geneve = dummy;
>>> - break;
>>> + hlist_for_each_entry_rcu(geneve, vni_list_head, hlist) {
>>> + if (!memcmp(gnvh->vni, geneve->vni, sizeof(geneve->vni)) &&
>>> + iph->saddr == geneve->remote.sin_addr.s_addr) {
>>> + return geneve;
>>> }
>>> }
>>> +
>>> + return rcu_dereference(gn->collect_md_tun);
>>> +}
>>
>> I think this operates differently from VXLAN (and GRE I believe) where
>> you can't have tunnels based on the VNI overlapping the
>> collect_md_tun. VXLAN is nice because it can go straight from the
>> socket to collecting metadata without having to an additional lookup
>> that doesn't give any additional information and it seems a little
>> simpler because we don't need to keep track of a flow-based device.
>> However, at the very least the behavior should be consistent.
>>
> This is how GRE works. But I can check for flow based device first to
> keep it consistent with vxlan.
Besides the lookup order, VXLAN will also disallow this configuration
at creation time.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
