Hi Eric,

Thanks for the comments.

On Mon, Nov 13, 2017 at 03:27:25PM -0500, Eric Garver wrote:
> > Fixes: 11387fe4a98 ("geneve: fix fill_info when using collect_metadata")
> > Signed-off-by: Hangbin Liu <liuhang...@gmail.com>
> > ---
> >  drivers/net/geneve.c | 28 +++++++++++-----------------
> >  1 file changed, 11 insertions(+), 17 deletions(-)
> > 
> > diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c
> > index ed51018..b010db7 100644
> > --- a/drivers/net/geneve.c
> > +++ b/drivers/net/geneve.c
> > @@ -1511,32 +1511,18 @@ static int geneve_fill_info(struct sk_buff *skb, 
> > const struct net_device *dev)
> >     if (nla_put_u32(skb, IFLA_GENEVE_ID, vni))
> >             goto nla_put_failure;
> >  
> > -   if (rtnl_dereference(geneve->sock4)) {
> > +   if (ip_tunnel_info_af(info) == AF_INET) {
> >             if (nla_put_in_addr(skb, IFLA_GENEVE_REMOTE,
> >                                 info->key.u.ipv4.dst))
> >                     goto nla_put_failure;
> >  
> 
> We can avoid passing up *_REMOTE{,6} for COLLECT_METADATA. They're
> mutually exclusive.

Do you mean something like

+       bool metadata = geneve->collect_md;
-       if (rtnl_dereference(geneve->sock4)) {
+       if (!metadata && ip_tunnel_info_af(info) == AF_INET) {

> 
> > -           if (nla_put_u8(skb, IFLA_GENEVE_UDP_CSUM,
> > -                          !!(info->key.tun_flags & TUNNEL_CSUM)))
> > -                   goto nla_put_failure;
> > -
> > -   }
> > -
> >  #if IS_ENABLED(CONFIG_IPV6)
> > -   if (rtnl_dereference(geneve->sock6)) {
> > +   } else {

and

-       if (rtnl_dereference(geneve->sock6)) {
+       } else if (!metadata) {

?
> > +
> > +   if (nla_put_u8(skb, IFLA_GENEVE_UDP_CSUM,
> > +                  !!(info->key.tun_flags & TUNNEL_CSUM)) ||
> > +       nla_put_u8(skb, IFLA_GENEVE_UDP_ZERO_CSUM6_TX,
> > +                  !(info->key.tun_flags & TUNNEL_CSUM)) ||
> 
> These two are nonsensical for COLLECT_METADATA as they come from the skb
> tun_info. They can be moved to inside the ipv4/ipv6 checks. For
> non-metadata, it doesn't make sense to pass them both as the tunnel is
> either ipv4 or ipv6, but not both.

OK, I will put them back to the ipv4/6 chunks.

Thanks
Hangbin

Reply via email to