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: <CAFdo_mXzqC_v5OkC6P012gFT_OmRO_yDTA0w96VhV-Lp3Hp7Fw@mail.gmail.com>
Date:	Tue, 22 Nov 2011 09:52:07 +0100
From:	Igor Maravić <igorm@....rs>
To:	jorge@...2.net
Cc:	davem@...emloft.net, netdev@...r.kernel.org
Subject: Re: MPLS for Linux kernel

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?
BR
Igor

2011/11/21 Jorge Boncompte [DTI2] <jorge@...2.net>:
> El 21/11/2011 19:29, David Miller escribió:
>> From: "Jorge Boncompte [DTI2]" <jorge@...2.net>
>> Date: Mon, 21 Nov 2011 16:01:26 +0100
>>
>>>      mpls-linux it is not ready to go upstream in my opinion.
>>
>> And can arguably be implemented in terms of openvswitch and packet scheduler actions.
>
>        I guess so, I have not really looked much at the openvswitch code. The MPLS
> code it is pretty self contained and in my opinion more tied to routing than to
> switching (*). I don't think it should be necessary an userspace daemon, like it
> seems necessary for openvswitch, just to bind a label to a route, the same way
> that it is not necessary a daemon to support VLAN's currently. The label
> signaling protocols are already complicated :)
>
>        I work in this code, like a lot of people do, because I have a use for it. I
> would really like to see it upstreamed but if it does not fit upstream plans, it
> is not a problem, this code it is not that hard to maintain.
>
>        In any case critics/reviews/patches are most than welcome.
>
> (*) The code that you implemented for 2.6.1 and that James R. Leu used in this
> codebase it is even more tied together to routing.
>
>
--
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