On Tue, May 21, 2013 at 4:39 PM, Jesse Gross <je...@nicira.com> wrote:
> On Mon, May 20, 2013 at 2:33 PM, Pravin B Shelar <pshe...@nicira.com> wrote:
>> Following patch restructures ovs tunneling and gre vport
>> implementation to make ovs tunneling more in sync with
>> upstream kernel tunneling.  Doing this tunneling code is
>> simplified as most of protocol processing on send and
>> recv is pushed to kernel tunneling.  For external ovs
>> module the code is moved to kernel compatibility code.
>>
>> Signed-off-by: Pravin B Shelar <pshe...@nicira.com>
>
> A couple more comments (just on the non-compat portions):
>
>> diff --git a/datapath/vport-gre.c b/datapath/vport-gre.c
>> index add17d9..f551976 100644
>> --- a/datapath/vport-gre.c
>> +++ b/datapath/vport-gre.c
>> -static __be32 be64_get_high32(__be64 x)
>> +static __be16 ovs_tnl_flags_to_gre_flags(u16 tun_flags)
> [...]
>> +       __be16 flags = 0;
>> +       if (tun_flags & OVS_TNL_F_CSUM)
>> +               flags |= TUNNEL_CSUM;
>> +       if (tun_flags & OVS_TNL_F_KEY)
>> +               flags |= TUNNEL_KEY;
>> +       return flags;
>>  }
>
> Is there any way that we can unify the tunnel flags values to avoid
> needing to do this conversion? I know the existing flags are based on
> the GRE values, so maybe we should push the conversion down there.
>
OVS can directly use TUNNEL_* flags, we just need to define
OVS_TNL_F_DONT_FRAGMENT equivalent there.

>>  /* Called with rcu_read_lock and BH disabled. */
>> -static int gre_rcv(struct sk_buff *skb)
>> +static int gre_rcv(struct sk_buff *skb,
>> +                  const struct tnl_ptk_info *tpi)
> [...]
>> +       hdr_len = _parse_header(tpi, &tnl_flags, &key);
>
> I would probably start the function name with a double underscore,
> just to be more consistent.
>
ok
>>         ovs_net = net_generic(dev_net(skb->dev), ovs_net_id);
>> -       if (is_gre64)
>> +       if (tpi->flags & TUNNEL_SEQ)
>
> I think the GRE64 check is not quite the same as before - it
> previously required both the key and the sequence number to be set,
> which seems more ideal to me.
>
ok.

>>                 vport = rcu_dereference(ovs_net->vport_net.gre64_vport);
>>         else
>>                 vport = rcu_dereference(ovs_net->vport_net.gre_vport);
>
> If neither of these vports are set, then should we return the packet
> back to the handler instead of accepting and freeing it? If so, then
> we might also want to move the check earlier in the function since it
> doesn't depend on the previous results.
ok, I ovs can return skb if there are no gre port.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Reply via email to