* [PATCH] RDMA/srpt: Filter out AGN bits
@ 2019-08-14 15:15 Bart Van Assche
2019-08-19 12:21 ` Jason Gunthorpe
0 siblings, 1 reply; 11+ messages in thread
From: Bart Van Assche @ 2019-08-14 15:15 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Leon Romanovsky, Doug Ledford, linux-rdma, Bart Van Assche, oulijun
The ib_srpt driver derives its default service GUID from the node GUID
of the first encountered HCA. Since that service GUID is passed to
ib_cm_listen(), the AGN bits must not be set. Since the AGN bits can
be set in the node GUID of RoCE HCAs, filter these bits out. This
patch avoids that loading the ib_srpt driver fails as follows for the
hns driver:
ib_srpt srpt_add_one(hns_0) failed.
Cc: oulijun <oulijun@huawei.com>
Reported-by: oulijun <oulijun@huawei.com>
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
---
drivers/infiniband/ulp/srpt/ib_srpt.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/infiniband/ulp/srpt/ib_srpt.c b/drivers/infiniband/ulp/srpt/ib_srpt.c
index e25c70a56be6..114bf8d6c82b 100644
--- a/drivers/infiniband/ulp/srpt/ib_srpt.c
+++ b/drivers/infiniband/ulp/srpt/ib_srpt.c
@@ -3109,7 +3109,8 @@ static void srpt_add_one(struct ib_device *device)
srpt_use_srq(sdev, sdev->port[0].port_attrib.use_srq);
if (!srpt_service_guid)
- srpt_service_guid = be64_to_cpu(device->node_guid);
+ srpt_service_guid = be64_to_cpu(device->node_guid) &
+ ~IB_SERVICE_ID_AGN_MASK;
if (rdma_port_get_link_layer(device, 1) == IB_LINK_LAYER_INFINIBAND)
sdev->cm_id = ib_create_cm_id(device, srpt_cm_handler, sdev);
--
2.23.0.rc1.153.gdeed80330f-goog
^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [PATCH] RDMA/srpt: Filter out AGN bits
2019-08-14 15:15 [PATCH] RDMA/srpt: Filter out AGN bits Bart Van Assche
@ 2019-08-19 12:21 ` Jason Gunthorpe
2019-08-19 13:40 ` Hal Rosenstock
2019-08-19 15:11 ` Bart Van Assche
0 siblings, 2 replies; 11+ messages in thread
From: Jason Gunthorpe @ 2019-08-19 12:21 UTC (permalink / raw)
To: Bart Van Assche, Hal Rosenstock
Cc: Leon Romanovsky, Doug Ledford, linux-rdma, oulijun
On Wed, Aug 14, 2019 at 08:15:07AM -0700, Bart Van Assche wrote:
> The ib_srpt driver derives its default service GUID from the node GUID
> of the first encountered HCA. Since that service GUID is passed to
> ib_cm_listen(), the AGN bits must not be set. Since the AGN bits can
> be set in the node GUID of RoCE HCAs, filter these bits out. This
> patch avoids that loading the ib_srpt driver fails as follows for the
> hns driver:
>
> ib_srpt srpt_add_one(hns_0) failed.
>
> Cc: oulijun <oulijun@huawei.com>
> Reported-by: oulijun <oulijun@huawei.com>
> Signed-off-by: Bart Van Assche <bvanassche@acm.org>
> drivers/infiniband/ulp/srpt/ib_srpt.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/infiniband/ulp/srpt/ib_srpt.c b/drivers/infiniband/ulp/srpt/ib_srpt.c
> index e25c70a56be6..114bf8d6c82b 100644
> +++ b/drivers/infiniband/ulp/srpt/ib_srpt.c
> @@ -3109,7 +3109,8 @@ static void srpt_add_one(struct ib_device *device)
> srpt_use_srq(sdev, sdev->port[0].port_attrib.use_srq);
>
> if (!srpt_service_guid)
> - srpt_service_guid = be64_to_cpu(device->node_guid);
> + srpt_service_guid = be64_to_cpu(device->node_guid) &
> + ~IB_SERVICE_ID_AGN_MASK;
This seems kind of sketchy, masking bits in the GUID is going to make
it non-unique.. Should we do this only for roce or something?
Hal, do you have any insight?
Jason
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] RDMA/srpt: Filter out AGN bits
2019-08-19 12:21 ` Jason Gunthorpe
@ 2019-08-19 13:40 ` Hal Rosenstock
2019-08-19 13:46 ` Jason Gunthorpe
2019-08-19 15:11 ` Bart Van Assche
1 sibling, 1 reply; 11+ messages in thread
From: Hal Rosenstock @ 2019-08-19 13:40 UTC (permalink / raw)
To: Jason Gunthorpe, Bart Van Assche, Hal Rosenstock
Cc: Leon Romanovsky, Doug Ledford, linux-rdma, oulijun
On 8/19/2019 8:21 AM, Jason Gunthorpe wrote:
> On Wed, Aug 14, 2019 at 08:15:07AM -0700, Bart Van Assche wrote:
>> The ib_srpt driver derives its default service GUID from the node GUID
>> of the first encountered HCA. Since that service GUID is passed to
>> ib_cm_listen(), the AGN bits must not be set. Since the AGN bits can
>> be set in the node GUID of RoCE HCAs, filter these bits out. This
>> patch avoids that loading the ib_srpt driver fails as follows for the
>> hns driver:
>>
>> ib_srpt srpt_add_one(hns_0) failed.
>>
>> Cc: oulijun <oulijun@huawei.com>
>> Reported-by: oulijun <oulijun@huawei.com>
>> Signed-off-by: Bart Van Assche <bvanassche@acm.org>
>> drivers/infiniband/ulp/srpt/ib_srpt.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/infiniband/ulp/srpt/ib_srpt.c b/drivers/infiniband/ulp/srpt/ib_srpt.c
>> index e25c70a56be6..114bf8d6c82b 100644
>> +++ b/drivers/infiniband/ulp/srpt/ib_srpt.c
>> @@ -3109,7 +3109,8 @@ static void srpt_add_one(struct ib_device *device)
>> srpt_use_srq(sdev, sdev->port[0].port_attrib.use_srq);
>>
>> if (!srpt_service_guid)
>> - srpt_service_guid = be64_to_cpu(device->node_guid);
>> + srpt_service_guid = be64_to_cpu(device->node_guid) &
>> + ~IB_SERVICE_ID_AGN_MASK;
>
> This seems kind of sketchy, masking bits in the GUID is going to make
> it non-unique.. Should we do this only for roce or something?
>
> Hal, do you have any insight?
include/rdma/ib_cm.h:#define IB_SERVICE_ID_AGN_MASK
cpu_to_be64(0xFF00000000000000ULL)
IB_SERVICE_ID_AGN_MASK masks entire first byte of OUI which seems like
too much to me as it contains company related bits.
Would it work just masking the first 2 bits (local/global and X bits) ?
-- Hal
> Jason
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] RDMA/srpt: Filter out AGN bits
2019-08-19 13:40 ` Hal Rosenstock
@ 2019-08-19 13:46 ` Jason Gunthorpe
2019-08-19 13:49 ` Hal Rosenstock
0 siblings, 1 reply; 11+ messages in thread
From: Jason Gunthorpe @ 2019-08-19 13:46 UTC (permalink / raw)
To: Hal Rosenstock
Cc: Bart Van Assche, Hal Rosenstock, Leon Romanovsky, Doug Ledford,
linux-rdma, oulijun
On Mon, Aug 19, 2019 at 09:40:24AM -0400, Hal Rosenstock wrote:
> On 8/19/2019 8:21 AM, Jason Gunthorpe wrote:
> > On Wed, Aug 14, 2019 at 08:15:07AM -0700, Bart Van Assche wrote:
> >> The ib_srpt driver derives its default service GUID from the node GUID
> >> of the first encountered HCA. Since that service GUID is passed to
> >> ib_cm_listen(), the AGN bits must not be set. Since the AGN bits can
> >> be set in the node GUID of RoCE HCAs, filter these bits out. This
> >> patch avoids that loading the ib_srpt driver fails as follows for the
> >> hns driver:
What is the actual problem anyhow? Is some roce GUID using the local
bits and overlapping with the IB_CM_ASSIGN_SERVICE_ID?
Ie generated VF MAC or something?
> >> ib_srpt srpt_add_one(hns_0) failed.
> >>
> >> Cc: oulijun <oulijun@huawei.com>
> >> Reported-by: oulijun <oulijun@huawei.com>
> >> Signed-off-by: Bart Van Assche <bvanassche@acm.org>
> >> drivers/infiniband/ulp/srpt/ib_srpt.c | 3 ++-
> >> 1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/infiniband/ulp/srpt/ib_srpt.c b/drivers/infiniband/ulp/srpt/ib_srpt.c
> >> index e25c70a56be6..114bf8d6c82b 100644
> >> +++ b/drivers/infiniband/ulp/srpt/ib_srpt.c
> >> @@ -3109,7 +3109,8 @@ static void srpt_add_one(struct ib_device *device)
> >> srpt_use_srq(sdev, sdev->port[0].port_attrib.use_srq);
> >>
> >> if (!srpt_service_guid)
> >> - srpt_service_guid = be64_to_cpu(device->node_guid);
> >> + srpt_service_guid = be64_to_cpu(device->node_guid) &
> >> + ~IB_SERVICE_ID_AGN_MASK;
> >
> > This seems kind of sketchy, masking bits in the GUID is going to make
> > it non-unique.. Should we do this only for roce or something?
> >
> > Hal, do you have any insight?
>
> include/rdma/ib_cm.h:#define IB_SERVICE_ID_AGN_MASK
> cpu_to_be64(0xFF00000000000000ULL)
>
> IB_SERVICE_ID_AGN_MASK masks entire first byte of OUI which seems like
> too much to me as it contains company related bits.
>
> Would it work just masking the first 2 bits (local/global and X bits) ?
Maybe if we see a local GUID it should generate a random global GUID
instead.
Jason
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] RDMA/srpt: Filter out AGN bits
2019-08-19 13:46 ` Jason Gunthorpe
@ 2019-08-19 13:49 ` Hal Rosenstock
0 siblings, 0 replies; 11+ messages in thread
From: Hal Rosenstock @ 2019-08-19 13:49 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Bart Van Assche, Hal Rosenstock, Leon Romanovsky, Doug Ledford,
linux-rdma, oulijun
On 8/19/2019 9:46 AM, Jason Gunthorpe wrote:
> On Mon, Aug 19, 2019 at 09:40:24AM -0400, Hal Rosenstock wrote:
>> On 8/19/2019 8:21 AM, Jason Gunthorpe wrote:
>>> On Wed, Aug 14, 2019 at 08:15:07AM -0700, Bart Van Assche wrote:
>>>> The ib_srpt driver derives its default service GUID from the node GUID
>>>> of the first encountered HCA. Since that service GUID is passed to
>>>> ib_cm_listen(), the AGN bits must not be set. Since the AGN bits can
>>>> be set in the node GUID of RoCE HCAs, filter these bits out. This
>>>> patch avoids that loading the ib_srpt driver fails as follows for the
>>>> hns driver:
>
> What is the actual problem anyhow? Is some roce GUID using the local
> bits and overlapping with the IB_CM_ASSIGN_SERVICE_ID?
>
> Ie generated VF MAC or something?
>
>>>> ib_srpt srpt_add_one(hns_0) failed.
>>>>
>>>> Cc: oulijun <oulijun@huawei.com>
>>>> Reported-by: oulijun <oulijun@huawei.com>
>>>> Signed-off-by: Bart Van Assche <bvanassche@acm.org>
>>>> drivers/infiniband/ulp/srpt/ib_srpt.c | 3 ++-
>>>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/infiniband/ulp/srpt/ib_srpt.c b/drivers/infiniband/ulp/srpt/ib_srpt.c
>>>> index e25c70a56be6..114bf8d6c82b 100644
>>>> +++ b/drivers/infiniband/ulp/srpt/ib_srpt.c
>>>> @@ -3109,7 +3109,8 @@ static void srpt_add_one(struct ib_device *device)
>>>> srpt_use_srq(sdev, sdev->port[0].port_attrib.use_srq);
>>>>
>>>> if (!srpt_service_guid)
>>>> - srpt_service_guid = be64_to_cpu(device->node_guid);
>>>> + srpt_service_guid = be64_to_cpu(device->node_guid) &
>>>> + ~IB_SERVICE_ID_AGN_MASK;
>>>
>>> This seems kind of sketchy, masking bits in the GUID is going to make
>>> it non-unique.. Should we do this only for roce or something?
>>>
>>> Hal, do you have any insight?
>>
>> include/rdma/ib_cm.h:#define IB_SERVICE_ID_AGN_MASK
>> cpu_to_be64(0xFF00000000000000ULL)
>>
>> IB_SERVICE_ID_AGN_MASK masks entire first byte of OUI which seems like
>> too much to me as it contains company related bits.
>>
>> Would it work just masking the first 2 bits (local/global and X bits) ?
>
> Maybe if we see a local GUID it should generate a random global GUID
> instead.
I think the OpenIB OUI could be used for that if you want...
> Jason
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] RDMA/srpt: Filter out AGN bits
2019-08-19 12:21 ` Jason Gunthorpe
2019-08-19 13:40 ` Hal Rosenstock
@ 2019-08-19 15:11 ` Bart Van Assche
2019-08-19 15:17 ` Jason Gunthorpe
1 sibling, 1 reply; 11+ messages in thread
From: Bart Van Assche @ 2019-08-19 15:11 UTC (permalink / raw)
To: Jason Gunthorpe, Hal Rosenstock
Cc: Leon Romanovsky, Doug Ledford, linux-rdma, oulijun
On 8/19/19 5:21 AM, Jason Gunthorpe wrote:
> On Wed, Aug 14, 2019 at 08:15:07AM -0700, Bart Van Assche wrote:
>> The ib_srpt driver derives its default service GUID from the node GUID
>> of the first encountered HCA. Since that service GUID is passed to
>> ib_cm_listen(), the AGN bits must not be set. Since the AGN bits can
>> be set in the node GUID of RoCE HCAs, filter these bits out. This
>> patch avoids that loading the ib_srpt driver fails as follows for the
>> hns driver:
>>
>> ib_srpt srpt_add_one(hns_0) failed.
>>
>> Cc: oulijun <oulijun@huawei.com>
>> Reported-by: oulijun <oulijun@huawei.com>
>> Signed-off-by: Bart Van Assche <bvanassche@acm.org>
>> drivers/infiniband/ulp/srpt/ib_srpt.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/infiniband/ulp/srpt/ib_srpt.c b/drivers/infiniband/ulp/srpt/ib_srpt.c
>> index e25c70a56be6..114bf8d6c82b 100644
>> +++ b/drivers/infiniband/ulp/srpt/ib_srpt.c
>> @@ -3109,7 +3109,8 @@ static void srpt_add_one(struct ib_device *device)
>> srpt_use_srq(sdev, sdev->port[0].port_attrib.use_srq);
>>
>> if (!srpt_service_guid)
>> - srpt_service_guid = be64_to_cpu(device->node_guid);
>> + srpt_service_guid = be64_to_cpu(device->node_guid) &
>> + ~IB_SERVICE_ID_AGN_MASK;
>
> This seems kind of sketchy, masking bits in the GUID is going to make
> it non-unique.. Should we do this only for roce or something?
Hi Jason and Hal,
The I/O controller GUID can be used in the srp_daemon configuration file
for filtering purposes. The srp_daemon only supports IB networks.
In the IBTA spec I found the following about the I/O controller GUID:
"An EUI-64 GUID used to uniquely identify the controller. This could be
the same one as the Node/Port GUID if there is only one controller."
Does uniqueness of the I/O controller GUID only matter in InfiniBand
networks or does it also matter in other RDMA networks?
How about using 0 as default value for the srpt_service_guid in RoCE
networks?
Thanks,
Bart.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] RDMA/srpt: Filter out AGN bits
2019-08-19 15:11 ` Bart Van Assche
@ 2019-08-19 15:17 ` Jason Gunthorpe
2019-08-19 15:45 ` Bart Van Assche
0 siblings, 1 reply; 11+ messages in thread
From: Jason Gunthorpe @ 2019-08-19 15:17 UTC (permalink / raw)
To: Bart Van Assche
Cc: Hal Rosenstock, Leon Romanovsky, Doug Ledford, linux-rdma, oulijun
On Mon, Aug 19, 2019 at 08:11:21AM -0700, Bart Van Assche wrote:
> On 8/19/19 5:21 AM, Jason Gunthorpe wrote:
> > On Wed, Aug 14, 2019 at 08:15:07AM -0700, Bart Van Assche wrote:
> > > The ib_srpt driver derives its default service GUID from the node GUID
> > > of the first encountered HCA. Since that service GUID is passed to
> > > ib_cm_listen(), the AGN bits must not be set. Since the AGN bits can
> > > be set in the node GUID of RoCE HCAs, filter these bits out. This
> > > patch avoids that loading the ib_srpt driver fails as follows for the
> > > hns driver:
> > >
> > > ib_srpt srpt_add_one(hns_0) failed.
> > >
> > > Cc: oulijun <oulijun@huawei.com>
> > > Reported-by: oulijun <oulijun@huawei.com>
> > > Signed-off-by: Bart Van Assche <bvanassche@acm.org>
> > > drivers/infiniband/ulp/srpt/ib_srpt.c | 3 ++-
> > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/infiniband/ulp/srpt/ib_srpt.c b/drivers/infiniband/ulp/srpt/ib_srpt.c
> > > index e25c70a56be6..114bf8d6c82b 100644
> > > +++ b/drivers/infiniband/ulp/srpt/ib_srpt.c
> > > @@ -3109,7 +3109,8 @@ static void srpt_add_one(struct ib_device *device)
> > > srpt_use_srq(sdev, sdev->port[0].port_attrib.use_srq);
> > > if (!srpt_service_guid)
> > > - srpt_service_guid = be64_to_cpu(device->node_guid);
> > > + srpt_service_guid = be64_to_cpu(device->node_guid) &
> > > + ~IB_SERVICE_ID_AGN_MASK;
> >
> > This seems kind of sketchy, masking bits in the GUID is going to make
> > it non-unique.. Should we do this only for roce or something?
>
> Hi Jason and Hal,
>
> The I/O controller GUID can be used in the srp_daemon configuration file for
> filtering purposes. The srp_daemon only supports IB networks.
>
> In the IBTA spec I found the following about the I/O controller GUID: "An
> EUI-64 GUID used to uniquely identify the controller. This could be the same
> one as the Node/Port GUID if there is only one controller."
Yes, and the CM uses a magic GUID to indicate service ID selection,
and it looks like that magic GUID was *very* poorly choosen. It also
looks like it is stealth ABI
> Does uniqueness of the I/O controller GUID only matter in InfiniBand
> networks or does it also matter in other RDMA networks?
>
> How about using 0 as default value for the srpt_service_guid in RoCE
> networks?
How does SRP connection management even work on RoCE?? The CM MADs
still carry a service_id? How do the sides exchange the service ID to
start the connection? Or is it ultimately overriden in the CM to use
an IP port based service ID?
Jason
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] RDMA/srpt: Filter out AGN bits
2019-08-19 15:17 ` Jason Gunthorpe
@ 2019-08-19 15:45 ` Bart Van Assche
2019-08-19 16:16 ` Jason Gunthorpe
0 siblings, 1 reply; 11+ messages in thread
From: Bart Van Assche @ 2019-08-19 15:45 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Hal Rosenstock, Leon Romanovsky, Doug Ledford, linux-rdma, oulijun
On 8/19/19 8:17 AM, Jason Gunthorpe wrote:
> On Mon, Aug 19, 2019 at 08:11:21AM -0700, Bart Van Assche wrote:
>> Does uniqueness of the I/O controller GUID only matter in InfiniBand
>> networks or does it also matter in other RDMA networks?
>>
>> How about using 0 as default value for the srpt_service_guid in RoCE
>> networks?
>
> How does SRP connection management even work on RoCE?? The CM MADs
> still carry a service_id? How do the sides exchange the service ID to
> start the connection? Or is it ultimately overriden in the CM to use
> an IP port based service ID?
The ib_srpt kernel driver would have to set id_ext to a unique value if
srpt_service_guid would be zero since the SRP initiator kernel driver
uses the IOC GUID + id_ext + initiator_ext combination in its connection
uniqueness check (srp_conn_unique()).
The ib_srp kernel driver supports both the IB/CM and the RDMA/CM. The
srp_daemon software tells ib_srp to use the IB/CM. Software like
blktests tells ib_srp to use the RDMA/CM. From
https://github.com/osandov/blktests/blob/master/tests/srp/rc:
srp_single_login \
"id_ext=$ioc_guid,ioc_guid=$ioc_guid,dest=$dest,$add_param" \
"$p/add_target"
The most important parameter in the login string is $dest. That is a
string with the following format:
<IP address>:<port number>.
Bart.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] RDMA/srpt: Filter out AGN bits
2019-08-19 15:45 ` Bart Van Assche
@ 2019-08-19 16:16 ` Jason Gunthorpe
2019-08-19 16:48 ` Bart Van Assche
0 siblings, 1 reply; 11+ messages in thread
From: Jason Gunthorpe @ 2019-08-19 16:16 UTC (permalink / raw)
To: Bart Van Assche
Cc: Hal Rosenstock, Leon Romanovsky, Doug Ledford, linux-rdma, oulijun
On Mon, Aug 19, 2019 at 08:45:58AM -0700, Bart Van Assche wrote:
> On 8/19/19 8:17 AM, Jason Gunthorpe wrote:
> > On Mon, Aug 19, 2019 at 08:11:21AM -0700, Bart Van Assche wrote:
> > > Does uniqueness of the I/O controller GUID only matter in InfiniBand
> > > networks or does it also matter in other RDMA networks?
> > >
> > > How about using 0 as default value for the srpt_service_guid in RoCE
> > > networks?
> >
> > How does SRP connection management even work on RoCE?? The CM MADs
> > still carry a service_id? How do the sides exchange the service ID to
> > start the connection? Or is it ultimately overriden in the CM to use
> > an IP port based service ID?
>
> The ib_srpt kernel driver would have to set id_ext to a unique value if
> srpt_service_guid would be zero since the SRP initiator kernel driver uses
> the IOC GUID + id_ext + initiator_ext combination in its connection
> uniqueness check (srp_conn_unique()).
Sounds like you should just generate something random for RDMA/CM mode ?
Still a bit confused how this is usable though if the initiating side
needs the service ID?
Jason
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] RDMA/srpt: Filter out AGN bits
2019-08-19 16:16 ` Jason Gunthorpe
@ 2019-08-19 16:48 ` Bart Van Assche
2019-08-20 17:08 ` Doug Ledford
0 siblings, 1 reply; 11+ messages in thread
From: Bart Van Assche @ 2019-08-19 16:48 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Hal Rosenstock, Leon Romanovsky, Doug Ledford, linux-rdma, oulijun
On 8/19/19 9:16 AM, Jason Gunthorpe wrote:
> On Mon, Aug 19, 2019 at 08:45:58AM -0700, Bart Van Assche wrote:
>> On 8/19/19 8:17 AM, Jason Gunthorpe wrote:
>>> On Mon, Aug 19, 2019 at 08:11:21AM -0700, Bart Van Assche wrote:
>>>> Does uniqueness of the I/O controller GUID only matter in InfiniBand
>>>> networks or does it also matter in other RDMA networks?
>>>>
>>>> How about using 0 as default value for the srpt_service_guid in RoCE
>>>> networks?
>>>
>>> How does SRP connection management even work on RoCE?? The CM MADs
>>> still carry a service_id? How do the sides exchange the service ID to
>>> start the connection? Or is it ultimately overriden in the CM to use
>>> an IP port based service ID?
>>
>> The ib_srpt kernel driver would have to set id_ext to a unique value if
>> srpt_service_guid would be zero since the SRP initiator kernel driver uses
>> the IOC GUID + id_ext + initiator_ext combination in its connection
>> uniqueness check (srp_conn_unique()).
>
> Sounds like you should just generate something random for RDMA/CM mode ?
>
> Still a bit confused how this is usable though if the initiating side
> needs the service ID?
Hi Jason,
When I read Lijun Ou's e-mails for the first time I was assuming that my
patch had been tested on top of a recent kernel. After having reread
these e-mails I think my patch had been tested on top of kernel v4.14
and is not necessary for more recent kernels. So I think we can drop the
patch at the start of this e-mail thread.
Bart.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] RDMA/srpt: Filter out AGN bits
2019-08-19 16:48 ` Bart Van Assche
@ 2019-08-20 17:08 ` Doug Ledford
0 siblings, 0 replies; 11+ messages in thread
From: Doug Ledford @ 2019-08-20 17:08 UTC (permalink / raw)
To: Bart Van Assche, Jason Gunthorpe
Cc: Hal Rosenstock, Leon Romanovsky, linux-rdma, oulijun
[-- Attachment #1: Type: text/plain, Size: 710 bytes --]
On Mon, 2019-08-19 at 09:48 -0700, Bart Van Assche wrote:
> Hi Jason,
>
> When I read Lijun Ou's e-mails for the first time I was assuming that
> my
> patch had been tested on top of a recent kernel. After having reread
> these e-mails I think my patch had been tested on top of kernel v4.14
> and is not necessary for more recent kernels. So I think we can drop
> the
> patch at the start of this e-mail thread.
Hi Bart,
Thanks for the heads up. I'll drop this out of patchworks and we can
revisit things if that turns out to be incorrect.
--
Doug Ledford <dledford@redhat.com>
GPG KeyID: B826A3330E572FDD
Fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2019-08-20 17:08 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-08-14 15:15 [PATCH] RDMA/srpt: Filter out AGN bits Bart Van Assche
2019-08-19 12:21 ` Jason Gunthorpe
2019-08-19 13:40 ` Hal Rosenstock
2019-08-19 13:46 ` Jason Gunthorpe
2019-08-19 13:49 ` Hal Rosenstock
2019-08-19 15:11 ` Bart Van Assche
2019-08-19 15:17 ` Jason Gunthorpe
2019-08-19 15:45 ` Bart Van Assche
2019-08-19 16:16 ` Jason Gunthorpe
2019-08-19 16:48 ` Bart Van Assche
2019-08-20 17:08 ` Doug Ledford
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.