netdev - Re: MPLS for Linux kernel

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: <4ECB95D7.7030702@dti2.net>
Date:	Tue, 22 Nov 2011 13:30:15 +0100
From:	"Jorge Boncompte [DTI2]" <jorge@...2.net>
To:	igorm@....rs
CC:	netdev@...r.kernel.org, davem@...emloft.net
Subject: Re: MPLS for Linux kernel

El 22/11/2011 9:52, Igor Maravić escribió:
> What are the main reasons for You to think that mpls-linux is not
> ready to go upstream?
> As I said, I fixed a lot of bugs so code can be run with all the
> kernel hacking options enabled, without causing panics and oopses.
> Also fixed a lot of other things and added preprocessor if statements
> where code is intertwined with normal kernel code, so I'm sure that it
> want break existing kernel compilation if the kernel is compiled
> without MPLS.
> Why would it be so hard to implemented it in terms of packet scheduler?

	First, please, don't top post.

	You keep insisting in that you fixed a lot of things, but you have provided a
git tree with just one big commit and say that have taken some of my patches on
it, could you please provide patches on TOP of the sourceforge code for the
things that are not fixed there? And for the new features like the MIB stats
work that you have done? It seems to me that you have not noticed that while
fixing bugs I have reworked a lot of code to make it cleaner or simpler, simply
deleted it and fixed the style.

	What's needs to be done, and it's on my TODO list...

	The kernel code that is not commented out on the mpls-linux code when you build
the kernel it the shim layer and it's not done on purpose. This code was written
by James to be a generic feature of the networking layer. Now I am not sure that
it has any value keeping it and am for removing it.
	The other thing that probably I am going to remove is the labelspace support. I
don't see a use for it, and even Cisco doesn't implement it either that I know.
	Then we must rework the netlink interface to make it cleaner and extensible.
	Move the tunnel code to use the netlink interface and generic tunnel code.
	Check the dst's usages, there has been a lot of changes in the core kernel here
lately and I am not sure if we are using it correctly.
	Check the locking and RCU usage.
	Look for a way to remove the mpls_ptr from the net_device structure. There's
code on another branch that does a radix-tree lookup for every packet but I
would like something simpler/lighter.

	As I said I am not for implementing MPLS support on top of the openvswitch
stuff, that I don't know, like I don't think that we are going to port the
bridge, vlan, ip_gre, or even l2tp support over it, aren't we? :)

	I am committed to support this code as best as I can and try to get it merged
but I would be nice if at least I can receive I confirmation of where we are
heading on upstream.

	Regards,
		Jorge

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