netdev - Re: [PATCH] net/mlx5e: Allow removing representors netdev to other namespace

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: <CAJ3xEMgc6j=+AxRUwdYOT6_cP69fY-ThVVbF+4EqtZGQ+-Sjnw@mail.gmail.com>
Date:   Tue, 21 May 2019 19:44:53 +0300
From:   Or Gerlitz <gerlitz.or@...il.com>
To:     Tonghao Zhang <xiangxia.m.yue@...il.com>
Cc:     Roi Dayan <roid@...lanox.com>,
        Saeed Mahameed <saeedm@...lanox.com>,
        Linux Netdev List <netdev@...r.kernel.org>
Subject: Re: [PATCH] net/mlx5e: Allow removing representors netdev to other namespace

On Tue, May 21, 2019 at 7:36 AM Tonghao Zhang <xiangxia.m.yue@...il.com> wrote:
> On Tue, May 21, 2019 at 4:24 AM Or Gerlitz <gerlitz.or@...il.com> wrote:
> >
> > On Mon, May 20, 2019 at 3:19 PM <xiangxia.m.yue@...il.com> wrote:
> > >
> > > From: Tonghao Zhang <xiangxia.m.yue@...il.com>
> > >
> > > At most case, we use the ConnectX-5 NIC on compute node for VMs,
> > > but we will offload forwarding rules to NICs on gateway node.
> > > On the gateway node, we will install multiple NICs and set them to
> > > different dockers which contain different net namespace, different
> > > routing table. In this way, we can specify the agent process on one
> > > docker. More dockers mean more high throughput.
> >
> > The vport (uplink and VF) representor netdev stands for the e-switch
> > side of things. If you put different
> > vport devices to different namespaces, you will not be able to forward
> > between them. It's the NIC side of things
> > (VF netdevice) which can/should be put to namespaces.
> >
> > For example, with SW veth devices, suppose I we have two pairs
> > (v0,v1), (v2, v3) -- we create
> > a SW switch (linux bridge, ovs) with the uplink and v0/v2 as ports all
> > in a single name space
> > and we map v1 and v3 into application containers.
> >
> > I am missing how can you make any use with vport reps belonging to the
> > same HW e-switch
> > on different name-spaces, maybe send chart?
>    +---------------------------------------------------------+
>    |                                                         |
>    |                                                         |
>    |       docker01                 docker02                 |
>    |                                                         |
>    | +-----------------+      +------------------+           |
>    | |    NIC (rep/vf) |      |       NIC        |           |
>    | |                 |      |                  |   host    |
>    | |   +--------+    |      |   +---------+    |           |
>    | +-----------------+      +------------------+           |
>    |     |        |               |         |                |
>    +---------------------------------------------------------+
>          |        |               |         |
>          |        |         phy_port2       | phy_port3
>          |        |               |         |
>          |        |               |         |
> phy_port0|        |phy_port1      |         |
>          |        |               |         |
>          v        +               v         +
>
> For example, there are two NIC(4 phy ports) on the host, we set the
> one NIC to docker01(all rep and vf of this nic are set to docker01).
> and other one NIC are set to docker02. The docker01/docker02 run our
> agent which use the tc command to offload the rule. The NIC of
> docker01 will receive packets from phy_port1
> and do the QoS , NAT(pedit action) and then forward them to phy_port0.
> The NIC of docker02 do this in the same way.

I see, so in the case you described about, you are going to move **all** the
representors of a certain e-switch into **one** name-space -- this is something
we don't have to block. However, I think we did wanted to disallow moving
sub-set of the port reps into a name-space. Should look into that.

Or.