From: Martin Varghese <martinvarghesenokia@gmail.com>
To: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Cc: Network Development <netdev@vger.kernel.org>,
David Miller <davem@davemloft.net>,
Jonathan Corbet <corbet@lwn.net>,
scott.drennan@nokia.com, Jiri Benc <jbenc@redhat.com>,
martin.varghese@nokia.com
Subject: Re: [PATCH net-next 1/2] UDP tunnel encapsulation module for tunnelling different protocols like MPLS,IP,NSH etc.
Date: Mon, 11 Nov 2019 21:32:22 +0530 [thread overview]
Message-ID: <20191111160222.GA2765@martin-VirtualBox> (raw)
In-Reply-To: <CAF=yD-JeCV-AW2HO9inJt-yePUrBGQ9=M58fYr8f2CDHdNNpaA@mail.gmail.com>
On Thu, Nov 07, 2019 at 11:35:07AM -0500, Willem de Bruijn wrote:
> On Thu, Nov 7, 2019 at 11:12 AM Martin Varghese
> <martinvarghesenokia@gmail.com> wrote:
> >
> > On Thu, Nov 07, 2019 at 10:53:47AM -0500, Willem de Bruijn wrote:
> > > > > I do think that with close scrutiny there is a lot more room for code
> > > > > deduplication. Just look at the lower half of geneve_rx and
> > > > > bareudp_udp_encap_recv, for instance. This, too, is identical down to
> > > > > the comments. Indeed, is it fair to say that geneve was taken as the
> > > > > basis for this device?
> > > > >
> > > > > That said, even just avoiding duplicating those routing functions
> > > > > would be a good start.
> > > > >
> > > > > I'm harping on this because in other examples in the past where a new
> > > > > device was created by duplicating instead of factoring out code
> > > > > implementations diverge over time in bad ways due to optimizations,
> > > > > features and most importantly bugfixes being applied only to one
> > > > > instance or the other. See for instance tun.c and tap.c.
> > > > >
> > > > > Unrelated, an ipv6 socket can receive both ipv4 and ipv6 traffic if
> > > > > not setting the v6only bit, so does the device need to have separate
> > > > > sock4 and sock6 members? Both sockets currently lead to the same
> > > > > bareudp_udp_encap_recv callback function.
> > > >
> > > > I was checking this.AF_INET6 allows v6 and v4 mapped v6 address.
> > > > And it doesnot allow both at the same time.So we need both
> > > > sockets to support v4 and v6 at the same time.correct ?
> > >
> > > bareudp_create_sock currently creates an inet socket listening on
> > > INADDR_ANY and an inet6 socket listening on in6addr_any with v6only.
> > > If so, just the latter without v6only should offer the same.
> >
> > To receive and ipv4 packet in AF_INET6 packet we need to pass v4 address
> > in v6 format( v4 mapped v6 address). Is it not ?
>
> If the bareudp device binds to a specific port on all local addresses,
> which I think it's doing judging from what it passes to udp_sock_create
> (but I may very well be missing something), then in6addr_any alone will
> suffice to receive both v6 and v4 packets.
Must invokde udp_encap_enable explicitly from baredudp module during setup time.
Otherwise v4 packets will not land in encap_rcv handler.
next prev parent reply other threads:[~2019-11-11 16:02 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-08 9:48 [PATCH net-next 0/2] Bareudp Tunnel Module Martin Varghese
2019-10-08 9:48 ` [PATCH net-next 1/2] UDP tunnel encapsulation module for tunnelling different protocols like MPLS,IP,NSH etc Martin Varghese
2019-10-08 14:06 ` Jonathan Corbet
2019-10-08 14:57 ` Randy Dunlap
2019-10-08 16:04 ` Stephen Hemminger
2019-10-08 16:05 ` Stephen Hemminger
2019-10-08 16:28 ` Willem de Bruijn
2019-10-09 12:48 ` Martin Varghese
2019-10-09 14:58 ` Willem de Bruijn
2019-10-09 15:21 ` Willem de Bruijn
2019-10-09 15:42 ` Jiri Benc
2019-10-09 16:15 ` Willem de Bruijn
2019-10-18 20:03 ` Tom Herbert
2019-10-21 17:18 ` Jiri Benc
2019-10-17 13:20 ` Martin Varghese
2019-10-17 20:48 ` Willem de Bruijn
2019-10-18 8:20 ` Martin Varghese
2019-10-18 14:59 ` Willem de Bruijn
2019-10-23 2:40 ` Martin Varghese
2019-11-07 13:38 ` Martin Varghese
2019-11-07 15:53 ` Willem de Bruijn
2019-11-07 16:12 ` Martin Varghese
2019-11-07 16:35 ` Willem de Bruijn
2019-11-07 17:31 ` Jiri Benc
2019-11-07 18:59 ` Willem de Bruijn
2019-11-07 19:05 ` Jiri Benc
2019-11-07 19:13 ` Willem de Bruijn
2019-11-11 16:02 ` Martin Varghese [this message]
2019-11-11 21:45 ` Willem de Bruijn
2019-11-14 13:17 ` Martin Varghese
2019-10-08 9:49 ` [PATCH net-next 2/2] Special handling for IP & MPLS Martin Varghese
2019-10-08 14:58 ` Randy Dunlap
2019-10-08 16:09 ` Willem de Bruijn
2019-10-09 13:38 ` Martin Varghese
2019-10-09 15:06 ` Willem de Bruijn
2019-10-09 15:19 ` 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=20191111160222.GA2765@martin-VirtualBox \
--to=martinvarghesenokia@gmail.com \
--cc=corbet@lwn.net \
--cc=davem@davemloft.net \
--cc=jbenc@redhat.com \
--cc=martin.varghese@nokia.com \
--cc=netdev@vger.kernel.org \
--cc=scott.drennan@nokia.com \
--cc=willemdebruijn.kernel@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.