From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
To: Martin Varghese <martinvarghesenokia@gmail.com>
Cc: Willem de Bruijn <willemdebruijn.kernel@gmail.com>,
Network Development <netdev@vger.kernel.org>,
David Miller <davem@davemloft.net>,
corbet@lwn.net, Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>,
Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>,
scott.drennan@nokia.com, Jiri Benc <jbenc@redhat.com>,
martin.varghese@nokia.com
Subject: Re: [PATCH v3 net-next 1/2] UDP tunnel encapsulation module for tunnelling different protocols like MPLS,IP,NSH etc.
Date: Thu, 2 Jan 2020 14:55:30 -0500 [thread overview]
Message-ID: <CA+FuTSfznBBAZ0d0AqXeb9VqUoBQz+MZPLF6=EcQdpZiVz7dxw@mail.gmail.com> (raw)
In-Reply-To: <20191231153255.GA2327@martin-VirtualBox>
On Tue, Dec 31, 2019 at 10:33 AM Martin Varghese
<martinvarghesenokia@gmail.com> wrote:
>
> On Fri, Nov 29, 2019 at 01:18:36PM -0500, Willem de Bruijn wrote:
> > On Thu, Nov 28, 2019 at 11:25 AM Martin Varghese
> > <martinvarghesenokia@gmail.com> wrote:
> > >
> > > On Mon, Nov 18, 2019 at 12:23:09PM -0500, Willem de Bruijn wrote:
> > > > On Sat, Nov 16, 2019 at 12:45 AM Martin Varghese
> > > > <martinvarghesenokia@gmail.com> wrote:
> > > > >
> > > > > From: Martin Varghese <martin.varghese@nokia.com>
> > > > >
> > > > > The Bareudp tunnel module provides a generic L3 encapsulation
> > > > > tunnelling module for tunnelling different protocols like MPLS,
> > > > > IP,NSH etc inside a UDP tunnel.
> > > > >
> > > > > Signed-off-by: Martin Varghese <martin.varghese@nokia.com>
> >
> > > > > +static int bareudp_fill_metadata_dst(struct net_device *dev,
> > > > > + struct sk_buff *skb)
> > > > > +{
> > > > > + struct ip_tunnel_info *info = skb_tunnel_info(skb);
> > > > > + struct bareudp_dev *bareudp = netdev_priv(dev);
> > > > > + bool use_cache = ip_tunnel_dst_cache_usable(skb, info);
> > > > > +
> > > > > + if (ip_tunnel_info_af(info) == AF_INET) {
> > > > > + struct rtable *rt;
> > > > > + struct flowi4 fl4;
> > > > > +
> > > > > + rt = iptunnel_get_v4_rt(skb, dev, bareudp->net, &fl4, info,
> > > > > + use_cache);
> > > > > + if (IS_ERR(rt))
> > > > > + return PTR_ERR(rt);
> > > > > +
> > > > > + ip_rt_put(rt);
> > > > > + info->key.u.ipv4.src = fl4.saddr;
> > > > > +#if IS_ENABLED(CONFIG_IPV6)
> > > > > + } else if (ip_tunnel_info_af(info) == AF_INET6) {
> > > > > + struct dst_entry *dst;
> > > > > + struct flowi6 fl6;
> > > > > + struct bareudp_sock *bs6 = rcu_dereference(bareudp->sock);
> > > > > +
> > > > > + dst = ip6tunnel_get_dst(skb, dev, bareudp->net, bs6->sock, &fl6,
> > > > > + info, use_cache);
> > > > > + if (IS_ERR(dst))
> > > > > + return PTR_ERR(dst);
> > > > > +
> > > > > + dst_release(dst);
> > > > > + info->key.u.ipv6.src = fl6.saddr;
> > > > > +#endif
> > > > > + } else {
> > > > > + return -EINVAL;
> > > > > + }
> > > > > +
> > > > > + info->key.tp_src = udp_flow_src_port(bareudp->net, skb,
> > > > > + bareudp->sport_min,
> > > > > + USHRT_MAX, true);
> > > > > + info->key.tp_dst = bareudp->conf.port;
> > > > > + return 0;
> > > > > +}
> > > >
> > > > This can probably all be deduplicated with geneve_fill_metadata_dst
> > > > once both use iptunnel_get_v4_rt.
> > > >
> > >
> > > Do you have any preference of file to keep the common function
> >
> > Perhaps net/ipv4/udp_tunnel.c
>
> I was trying this change and i found i dont have a lot of generic code here.
>
> Populating L4 ports is function of the protocol implementation
> and it is differnt for geneve and for bareudp
If geneve can use iptunnel_get_v4_rt, then it seems like the only
implementation specific logic is deriving net and sk. Would it help to
just pass those explicitly to the shared helper
(udptunnel_fill_metadata_dst)?
It is hard to say without seeing the geneve conversion to
iptunnel_get_v4_rt. Maybe that throws up a constraint I'm missing.
Lacking that, I'll trust your judgment.
> The one thing we could do is to write a generic API to derive the
> tunnel src address.
>
> But since it is a very small piece i dont see much value add by making it
> generic and i prefer to keep the way as it is now
In that case, that sounds sensible.
>
> But i am open for both the option. What you think ?
>
>
>
next prev parent reply other threads:[~2020-01-02 19:56 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-16 5:43 [PATCH v3 net-next 0/2] Bare UDP L3 Encapsulation Module Martin Varghese
2019-11-16 5:44 ` [PATCH v3 net-next 1/2] UDP tunnel encapsulation module for tunnelling different protocols like MPLS,IP,NSH etc Martin Varghese
2019-11-18 17:23 ` Willem de Bruijn
2019-11-28 16:24 ` Martin Varghese
2019-11-29 18:18 ` Willem de Bruijn
2019-12-31 15:32 ` Martin Varghese
2020-01-02 19:55 ` Willem de Bruijn [this message]
2019-11-20 11:10 ` kbuild test robot
2019-11-16 5:45 ` [PATCH v3 net-next 2/2] Special handling for IP & MPLS Martin Varghese
2019-11-18 17:30 ` Willem de Bruijn
2019-11-28 16:12 ` Martin Varghese
2019-11-29 18:20 ` Willem de Bruijn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CA+FuTSfznBBAZ0d0AqXeb9VqUoBQz+MZPLF6=EcQdpZiVz7dxw@mail.gmail.com' \
--to=willemdebruijn.kernel@gmail.com \
--cc=corbet@lwn.net \
--cc=davem@davemloft.net \
--cc=jbenc@redhat.com \
--cc=kuznet@ms2.inr.ac.ru \
--cc=martin.varghese@nokia.com \
--cc=martinvarghesenokia@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=scott.drennan@nokia.com \
--cc=yoshfuji@linux-ipv6.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).