On Wed, Jun 7, 2017 at 6:48 PM, Jason Gunthorpe <jgunthorpe@xxxxxxxxxxxxxxxxxxxx> wrote: > On Wed, Jun 07, 2017 at 07:16:42AM +0300, Saeed Mahameed wrote: >> On Tue, Jun 6, 2017 at 7:17 PM, Jason Gunthorpe >> <jgunthorpe@xxxxxxxxxxxxxxxxxxxx> wrote: >> > On Tue, Jun 06, 2017 at 06:52:15AM +0000, Ilan Tayari wrote: >> > >> >> So neither the host stack nor the network are aware of them. >> >> They exist momentarily only on the internal traces on the board and not >> >> anywhere else. >> > >> > Is that really true? If you are creating rocee QPs' then the RDMA >> > stack sees this stuff and now we have buried a RDMA ULP inside an >> > ethernet driver which seems really wonky.. >> >> It is not an ethernet driver, mlx5_core provides both RDMA and >> ethernet interfaces to both mlx5_ib and the mlx5e netdevice. >> >> so it is perfectly capable of creating QPs on its own, after all it is >> the one creating QPs for the RDMA stack :). >> >> rdma_create_qp->mlx5_ib_create_qp->mlx5_core_create_qp. > > Wait, so you built a RDMA ULP inside your driver without using the > RDMA API? > No !! I am just showing you that the ib_core eventually will end up calling mlx5_core to create a QP. so mlx5_core can create the QP it self since it is the one eventually creating QPs. we just call mlx5_core_create_qp directly. > This keep getting more ugly :( > > What about security? What if user space sends some raw packets to the > FPGA - can it reprogram the ISPEC settings or worse? > No such thing. This QP is only for internal driver/HW communications, as it is faster from the existing command interface. it is not meant to be exposed for any raw user space usages at all, without proper standard API adapter of course. > Jason -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
