On Mon, May 16, 2016 at 7:46 PM, Doug Ledford <dledford@xxxxxxxxxx> wrote: > On 05/16/2016 12:31 PM, Matan Barak (External) wrote: >> On 16/05/2016 18:14, Doug Ledford wrote: >>> On 05/15/2016 08:57 AM, Or Gerlitz wrote: >>>> On some environments, such as certain SRIOV VF configurations, RoCE is >>>> not supported for an Ethernet port. Currently, the driver will not >>>> open IB device on that port. >>>> This is problematic, since we do want user-space RAW Ethernet >>>> (RAW_PACKET QPs) functionality to remain in place. For that end, >>>> enhance the relevant >>>> driver flows such that we do create a device instance in that case. >>> So this device is still going to present itself as a uverbs# device and >>> libibverbs is still going to try and access it, but when it comes time >>> for user applications to try and use it they will simply fail all QP >>> types except for RAW? Is there no way to distinguish between a device >>> with RoCE enabled and without? Doug, To answer your questions: YES there is a way, namely RDMA_CORE_CAP_PROT_ROCE and RDMA_CORE_PORT_IBA_ROCE - under this patch, when RoCE isn't supported we do create the device but not advertizing these caps. > OK, so you want a plain Ethernet device with QPs as a means of enabling > RDMA for Ethernet, but without the full blown Verbs support, just direct > data placement in memory. That's a reasonable thing to want to do. > However, I'm not sure I agree with the implementation here. It seems > very hackish. This setup probably deserves its own type setting in the > RDMA stack to differentiate it (aka, InfiniBand, OPA, RoCE, iWARP, > USNIC, Ethernet + QPs). Why? we should be doing things for a reason. There's no entity I know of in the stack which needs to be operative and is not b/c that new type you're suggesting was not defined. Or. -- 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
