netdev - Re: Summary lightweight tunnel discussion at NFWS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20150706130348.GA19361@pox.localdomain>
Date:	Mon, 6 Jul 2015 15:03:49 +0200
From:	Thomas Graf <tgraf@...g.ch>
To:	roopa <roopa@...ulusnetworks.com>
Cc:	ebiederm@...ssion.com, rshearma@...cade.com, davem@...emloft.net,
	netdev@...r.kernel.org
Subject: Re: Summary lightweight tunnel discussion at NFWS

On 07/04/15 at 11:21pm, roopa wrote:
> Thx. I have fixed this since,...did not realize it came in as part of this
> RFC series.
> >
> >Other than that I managed to rebase my changes onto yours and it
> >looks clean.
> Glad to know!. thanks Thomas. I had a few more changes (mostly cleanup/bug
> fixes, ipv6 support and mostly earlier feedback from you)
> in my local clone, pushed it to my github tree just now.

> This also tries to not use CONFIG_LWTUNNEL all over the place. I had it that
> way initially also because of fib struct members

The integration into the routing code looks much better now. Any
chance you can rebase your tree and squash it into logical
commits? I'm rebasing again onto yours and I think we should submit
all of this in a single series so everything can be reviewed in a
single thread.

> under #ifdef CONFIG_LWTUNNEL. (If we think at a later point that it is
> better to #ifdef CONFIG_LWTUNNEL fib struct members,
> I can bring some of that back in). And, Only control path (rtnetlink) for
> ipv6 mpls iptunnels has been tested.

All of this is only useful if distros enable this by default which
minimize the value of a config option quite a bit. I think what you
have your latest tree is a good balance.

> I have been thinking of moving lwtstate from rtable to struct dst_entry.
> I will also look at the dst_metadata.

I thought about the same. The introduction of dst_metadata makes
that a bit pointless because we don't want to store a pointer to the
tunnel metadata but allocate the metadata as a dst directly to avoid
the indirection. We need the separate code paths anyway until v6 and
v4 routing are merged so we would save very little while penalizing
everyone except rtable and fib6.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html