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]

Date:   Wed, 22 May 2019 09:25:45 +0800
From:   Tonghao Zhang <xiangxia.m.yue@...il.com>
To:     Or Gerlitz <gerlitz.or@...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 Wed, May 22, 2019 at 12:45 AM Or Gerlitz <gerlitz.or@...il.com> wrote:
>
> 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.
I review the reps of netronome nfp codes,  nfp does't set the
NETIF_F_NETNS_LOCAL to netdev->features.
And I changed the OFED codes which used for our product environment,
and then send this patch to upstream.
> Or.