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.
>>>
>>> Signed-off-by: Or Gerlitz <ogerlitz@xxxxxxxxxxxx>
>>> Reviewed-by: Matan Barak <matanb@xxxxxxxxxxxx>
>>
>> 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?
>>
>>
>
> It's a bit broken, but you could query gid_tbl_len in ibv_port_attr.
> If it's zero, RoCE can't be used anyway.
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).
--
Doug Ledford <dledford@xxxxxxxxxx>
GPG KeyID: 0E572FDD
Attachment:
signature.asc
Description: OpenPGP digital signature
