On 07/04/2014 02:31 PM, Bart Van Assche wrote:
On 07/04/14 13:54, Hannes Reinecke wrote:
SRP is capable of handling 64bit LUNs, so as we now have proper
support for it we can modify the driver to use the standard functions.
Cc: Bart van Assche <bvanassche@xxxxxxx>
Signed-off-by: Hannes Reinecke <hare@xxxxxxx>
---
drivers/infiniband/ulp/srp/ib_srp.c | 9 ++--
drivers/infiniband/ulp/srpt/ib_srpt.c | 81 +----------------------------------
2 files changed, 7 insertions(+), 83 deletions(-)
The SRP initiator and target drivers are independent drivers so this
should be two patches instead of one. Furthermore, I do not agree with
introducing a call to int_to_scsilun() in the hot path of the initiator
driver since that causes a small but unnecessary additional overhead.
Please keep in mind that there is no need to repeat the int_to_scsilun()
conversion for every I/O request. Hence my earlier proposal to cache the
int_to_scsilun() result.
What I would like to do is to provide accessor functions for the
scsi lun; I've started this already for the older SCSI parallel
drivers (see my earlier patch).
Once everything is moved over to accessors it should be trivial to
move from the current scsilun_to_int representation in struct
scsi_device to the 'real' LUN.
Adding another field would be bit of an overkill IMO, seeing that we
can achieve the very same thing with a bit of code reshuffling.
James, Christoph, what's your opinion on using accessors?
Would solve this issue nicely, and we can also use proper functions
for HBAs only capable of handling 32bit LUNs.
Drawback is that we would need accessors also for this capable of
handling full 64bit LUNs, thus potentially incur some overhead there.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
hare@xxxxxxx +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
