Hi, Jason
Thanks for the reply :-)
On 03/26/2015 10:13 PM, Jason Gunthorpe wrote:
> On Thu, Mar 26, 2015 at 05:58:20PM +0100, Michael Wang wrote:
>
>> The questions is just wondering how the transition method could be, but
>> if we have to do the changes for vendor, that sounds like a tough job...
> I would see changing how the information is represented in the struct
> as a follow on issue. The first patch should go through and replace
> all direct access to the link layer/transport/etc with an
> appropriately narrow is_XX() test like Doug was suggesting.
Sounds like a good plan, I'd like to change the second patch to
introduce these new helpers, later when we come to a good
solution, rework should be far more easier.
>
> That means looking at each code site and determining what it needs,
> making a is_XX for it and a kdoc describing exactly what is needed for
> the test to return true.
Basically I found there are three kind of check in current
implementation:
1. check transport type of device only
I'd like to use helper has_XX(device)
which means some port of the device has XX capability.
2. check link layer of device's port only
I'd like to use helper cap_XX(device, port)
which means the port has XX capability
3. check both the transport type and link layer
I'd like to use helper tech_XX(device, port)
which means the port of that device using technology
ib, iwrap, iboe(roce) ...
>
> The follow on patch can then rework the is_XX and drop the link
> layer/transport stuff..
>
> Some ideas for is_XX:
> IB compatible SA
> QP0 SMP mechanism
> IB SMP format
> OPA SMP format
> QP1 GMP mechanism
> IB compatible CM
> GID addressing
> IP/IPv6 addressing
> Ethernet VLAN
> ...
Let's discuss and figure out the right name in the thread of
v2 patch set, I guess there will be a lot to be correct :-P
Regards,
Michael Wang
>
> Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
