netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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>,
	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 net-next v4 1/2] net: UDP tunnel encapsulation module for
Date: Thu, 23 Jan 2020 20:20:23 +0530	[thread overview]
Message-ID: <20200123145023.GA6743@martin-VirtualBox> (raw)
In-Reply-To: <CA+FuTSfK0OxM8X2_n5GJOrYOpaxX6EFm4KW5j+Lzf5QqFp3hSg@mail.gmail.com>

On Wed, Jan 22, 2020 at 01:29:32PM -0500, Willem de Bruijn wrote:
> On Tue, Jan 21, 2020 at 12:51 PM 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>
> 
> This addresses the main points I raised. A few small points below,
> nothing serious. It could use more eye balls, but beyond those Acked
> from me.
> 
> > ---
> > Changes in v2:
> >      - Fixed documentation errors.
> >      - Converted documentation to rst format.
> >      - Moved ip tunnel rt lookup code to a common location.
> >      - Removed seperate v4 and v6 socket.
> >      - Added call to skb_ensure_writable before updating ethernet header.
> >      - Simplified bareudp_destroy_tunnels as deleting devices under a
> >        namespace is taken care be the default pernet exit code.
> >      - Fixed bareudp_change_mtu.
> >
> > Changes in v3:
> >      - Re-sending the patch again.
> >
> > Changes in v4:
> >      - Converted bareudp device to l3 device.
> 
> I didn't quite get this statement, but it encompasses the change to
> ARPHRD_NONE and introduction of gro_cells, I guess?
> 
> >      - Removed redundant fields in bareudp device.
> 
> > diff --git a/Documentation/networking/index.rst b/Documentation/networking/index.rst
> > index d07d985..ea3d604 100644
> > --- a/Documentation/networking/index.rst
> > +++ b/Documentation/networking/index.rst
> > @@ -33,6 +33,7 @@ Contents:
> >     tls
> >     tls-offload
> >     nfc
> > +   bareudp
> 
> if respinning: this list is mostly alphabetically ordened, perhaps
> insert before batman-adv
> 
> > diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
> > index dee7958..9726447 100644
> > --- a/drivers/net/Kconfig
> > +++ b/drivers/net/Kconfig
> > @@ -258,6 +258,19 @@ config GENEVE
> >           To compile this driver as a module, choose M here: the module
> >           will be called geneve.
> >
> > +config BAREUDP
> > +       tristate "Bare UDP Encapsulation"
> > +       depends on INET && NET_UDP_TUNNEL
> > +       depends on IPV6 || !IPV6
> > +       select NET_IP_TUNNEL
> > +       select GRO_CELLS
> 
> Depends on NET_UDP_TUNNEL plus selects NET_IP_TUNNEL seems odd.
> 
> NET_UDP_TUNNEL itself selects NET_IP_TUNNEL, so perhaps just select
> NET_UDP_TUNNEL.
> 
> I had to make that change to be able to get it in a .config after make
> defconfig.
> 
> 
> > +static int bareudp_change_mtu(struct net_device *dev, int new_mtu)
> > +{
> > +       dev->mtu = new_mtu;
> > +       return 0;
> > +}
> 
> If your ndo_change_mtu does nothing special, it can just rely on the
> assignment in __dev_set_mtu
>
yes.
we could  set dev_set_mtu in all the cases.ignore my previous reply
> > +/* Initialize the device structure. */
> > +static void bareudp_setup(struct net_device *dev)
> > +{
> > +       dev->netdev_ops = &bareudp_netdev_ops;
> > +       dev->needs_free_netdev = true;
> > +       SET_NETDEV_DEVTYPE(dev, &bareudp_type);
> > +       dev->features    |= NETIF_F_SG | NETIF_F_HW_CSUM;
> > +       dev->features    |= NETIF_F_RXCSUM;
> > +       dev->features    |= NETIF_F_GSO_SOFTWARE;
> > +       dev->hw_features |= NETIF_F_SG | NETIF_F_HW_CSUM | NETIF_F_RXCSUM;
> > +       dev->hw_features |= NETIF_F_GSO_SOFTWARE;
> > +       dev->hard_header_len = 0;
> > +       dev->addr_len = 0;
> > +       dev->mtu = 1500;
> 
> ETH_DATA_LEN?

  parent reply	other threads:[~2020-01-23 14:50 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-21 17:48 [PATCH net-next v4 0/2] Bare UDP L3 Encapsulation Module Martin Varghese
2020-01-21 17:50 ` [PATCH net-next v4 1/2] net: UDP tunnel encapsulation module for Martin Varghese
2020-01-22 18:29   ` Willem de Bruijn
2020-01-23  9:59     ` Martin Varghese
2020-01-23 14:50     ` Martin Varghese [this message]
2020-01-24  9:41   ` kbuild test robot
2020-01-24 13:30   ` kbuild test robot
2020-01-21 17:51 ` [PATCH net-next v4 2/2] net: Special handling for IP & MPLS Martin Varghese
2020-01-22 18:30   ` Willem de Bruijn
2020-01-23 10:00     ` Martin Varghese

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=20200123145023.GA6743@martin-VirtualBox \
    --to=martinvarghesenokia@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=netdev@vger.kernel.org \
    --cc=scott.drennan@nokia.com \
    --cc=willemdebruijn.kernel@gmail.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).