On Tue, 2021-01-19 at 20:10 +0800, Zhu Yanjun wrote:
> On Tue, Jan 19, 2021 at 6:57 PM <mwilck@xxxxxxxx> wrote:
> >
> > From: Martin Wilck <mwilck@xxxxxxxx>
> >
> > This reverts commit b2d2440430c0fdd5e0cad3efd6d1c9e3d3d02e5b.
> >
> > It's true that creating rxe on top of 802.1q interfaces doesn't
> > work.
> > Thus, commit fd49ddaf7e26 ("RDMA/rxe: prevent rxe creation on top
> > of vlan interface")
> > was absolutely correct.
> >
> > But b2d2440430c0 was incorrect assuming that with this change,
> > RDMA and VLAN don't work togehter at all. It just has to be
> > set up differently. Rather than creating rxe on top of the VLAN
> > interface, rxe must be created on top of the physical interface.
> > RDMA then works just fine through VLAN interfaces on top of that
> > physical interface, via the "upper device" logic.
>
> I read this commit log for several times. I can not get you.
> Can you show me by an example?
My test scenario which is broken by your patch uses a script that does
roughly the following:
# (set up eth0)
rdma link add rxe_eth0 type rxe netdev eth0
ip link add link eth0 name eth0.10 type vlan id 10
ip link set eth0.10 up
ip addr add 192.168.10.102/24 dev eth0.10
nvme discover -t rdma -a 192.168.10.101 -s 4420
192.168.10.101 is another host that configures the network
and rxe the same way, and has some nvmet targets.
=> fails with your patch applied, works otherwise.
Regards,
Martin
