On Tue, May 21, 2019 at 7:36 AM Tonghao Zhang <xiangxia.m....@gmail.com> wrote: > On Tue, May 21, 2019 at 4:24 AM Or Gerlitz <gerlitz...@gmail.com> wrote: > > > > On Mon, May 20, 2019 at 3:19 PM <xiangxia.m....@gmail.com> wrote: > > > > > > From: Tonghao Zhang <xiangxia.m....@gmail.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.
