Re: [PATCH net] geneve: show remote address and checksum info even after link down

[Hangbin Liu <haliu@redhat.com>]

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 <liuhangbin@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