From: David Lamparter <equinox@diac24.net>
To: Amine Kherbouche <amine.kherbouche@6wind.com>
Cc: netdev@vger.kernel.org, roopa@cumulusnetworks.com
Subject: Re: [PATCH 2/2] drivers: add vpls support
Date: Fri, 11 Aug 2017 14:55:47 +0200 [thread overview]
Message-ID: <20170811125547.GZ773745@eidolon> (raw)
In-Reply-To: <1502396917-14848-3-git-send-email-amine.kherbouche@6wind.com>
On Thu, Aug 10, 2017 at 10:28:37PM +0200, Amine Kherbouche wrote:
> This commit introduces the support of VPLS virtual device, that allows
> performing L2VPN multipoint to multipoint communication over MPLS PSN.
>
> VPLS device encap received ethernet frame over mpls packet and send it the
> output device, in the other direction, when receiving the right configured
> mpls packet, the matched mpls route calls the handler vpls function,
> then pulls out the mpls header and send it back the entry point via
> netif_rx().
>
> Two functions, mpls_entry_encode() and mpls_output_possible() are
> exported from mpls/internal.h to be able to use them inside vpls driver.
>
> Signed-off-by: Amine Kherbouche <amine.kherbouche@6wind.com>
This code is derivative of code that I authored; while you
significantly changed it I'd appreciate if you kept a hint of that.
Unfortunately, I also have some concerns with this patch...
> +#define VPLS_MAX_ID 256 /* Max VPLS WireID (arbitrary) */
There is no point in keeping a VPLS wire ID. Again, this was in the
README that accompanied my patchset:
- I made a design mistake with the wire ID. It's simply not needed. A
pseudowire can be identified by its incoming label. There is also some
really ugly code keeping an array of wires...
I don't even see where you're using the wire ID anymore at this point,
it might be a dead leftover from my code.
[...]
> +union vpls_nh {
> + struct in6_addr addr6;
> + struct in_addr addr;
> +};
> +
> +struct vpls_dst {
> + struct net_device *dev;
> + union vpls_nh addr;
> + u32 label_in, label_out;
> + u32 id;
> + u16 vlan_id;
I looked at VLAN support and decided against it because the bridge layer
can handle this perfectly fine by using the bridge's vlan support to tag
a port's pvid.
> + u8 via_table;
> + u8 flags;
> + u8 ttl;
> +};
[...]
> +struct vpls_priv {
> + struct net *encap_net;
> + struct vpls_dst dst;
> +};
> +
> +static struct nla_policy vpls_policy[IFLA_VPLS_MAX + 1] = {
> + [IFLA_VPLS_ID] = { .type = NLA_U32 },
> + [IFLA_VPLS_IN_LABEL] = { .type = NLA_U32 },
> + [IFLA_VPLS_OUT_LABEL] = { .type = NLA_U32 },
> + [IFLA_VPLS_OIF] = { .type = NLA_U32 },
> + [IFLA_VPLS_TTL] = { .type = NLA_U8 },
> + [IFLA_VPLS_VLANID] = { .type = NLA_U8 },
> + [IFLA_VPLS_NH] = { .type = NLA_U32 },
> + [IFLA_VPLS_NH6] = { .len = sizeof(struct in6_addr) },
> +};
The original patchset was point-to-multipoint in a single netdev, and
had some starts on optimized multicast support (which, admittedly, is a
bit of a fringe thing, but still.)
This patch implements a single pseudowire (so the name is kind of
misleading; it's a VLL / VPWS, multiple of which you'd use to build full
VPLS). However, you are now missing split-horizon ethernet bridging
support. How is that done here?
-David
P.S.: for anyone curious, the original patchset is at
https://github.com/eqvinox/vpls-linux-kernel
I didn't go ahead with posting it because I felt there were several
things where I'd want to change the design, hence this README:
https://github.com/eqvinox/vpls-linux-kernel/commit/81c809d6f9c40c0332098e13fcad65144aa51795
next prev parent reply other threads:[~2017-08-11 12:55 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-10 20:28 [RFC PATCH 0/2] Support of VPLS MPLS Amine Kherbouche
2017-08-10 20:28 ` [PATCH 1/2] mpls: add handlers Amine Kherbouche
2017-08-11 12:34 ` David Lamparter
2017-08-11 14:37 ` Roopa Prabhu
2017-08-12 13:35 ` Amine Kherbouche
2017-08-13 3:29 ` Roopa Prabhu
2017-08-15 9:37 ` David Lamparter
2017-08-16 5:30 ` Roopa Prabhu
2017-08-16 10:24 ` Amine Kherbouche
2017-08-10 20:28 ` [PATCH 2/2] drivers: add vpls support Amine Kherbouche
2017-08-11 12:55 ` David Lamparter [this message]
2017-08-11 15:14 ` Roopa Prabhu
2017-08-12 13:40 ` Amine Kherbouche
2017-08-13 2:46 ` Roopa Prabhu
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=20170811125547.GZ773745@eidolon \
--to=equinox@diac24.net \
--cc=amine.kherbouche@6wind.com \
--cc=netdev@vger.kernel.org \
--cc=roopa@cumulusnetworks.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.