On 6/23/10 4:36 PM, Robert Love wrote:
> On Fri, 2010-06-18 at 10:00 -0700, Joe Eykholt wrote:
>> Add pre-zeroed space after the allocation for fc_rport_priv
>> for use by the lower-level driver.
>>
>> This is primarily for VN2VN FIP mode, but could be used in
>> other ways someday.
>>
>> The space required is specified in lport->rport_priv_size.
>>
>> Signed-off-by: Joe Eykholt<[email protected]>
>> ---
>>   drivers/scsi/libfc/fc_rport.c |    2 +-
>>   include/scsi/libfc.h          |    2 ++
>>   2 files changed, 3 insertions(+), 1 deletions(-)
>>
>>
>> diff --git a/drivers/scsi/libfc/fc_rport.c b/drivers/scsi/libfc/fc_rport.c
>> index 6b56973..6d68482 100644
>> --- a/drivers/scsi/libfc/fc_rport.c
>> +++ b/drivers/scsi/libfc/fc_rport.c
>> @@ -127,7 +127,7 @@ static struct fc_rport_priv *fc_rport_create(struct 
>> fc_lport *lport,
>>      if (rdata)
>>              return rdata;
>>
>> -    rdata = kzalloc(sizeof(*rdata), GFP_KERNEL);
>> +    rdata = kzalloc(sizeof(*rdata) + lport->rport_priv_size, GFP_KERNEL);
>>      if (!rdata)
>>              return NULL;
>>
>> diff --git a/include/scsi/libfc.h b/include/scsi/libfc.h
>> index b0310b9..fcbee8c 100644
>> --- a/include/scsi/libfc.h
>> +++ b/include/scsi/libfc.h
>> @@ -799,6 +799,7 @@ struct fc_disc {
>>    * @mfs:                   The maximum Fibre Channel payload size
>>    * @max_retry_count:       The maximum retry attempts
>>    * @max_rport_retry_count: The maximum remote port retry attempts
>> + * @rport_priv_size:       Size needed by driver after struct fc_rport_priv
>>    * @lro_xid:               The maximum XID for LRO
>>    * @lso_max:               The maximum large offload send size
>>    * @fcts:                  FC-4 type mask
>> @@ -848,6 +849,7 @@ struct fc_lport {
>>      u32                            mfs;
>>      u8                             max_retry_count;
>>      u8                             max_rport_retry_count;
>> +    u16                            rport_priv_size;
>
> Just a thought- maybe this should be in the TT. I'd like to say that the
> TT is more for LLD requirements/settings and an lport instance is more
> for non-configurable operational members, but we already have a lot of
> "capabilities" in the lport. It's clear that we don't have that strong
> of a distinction between what goes in the TT and what goes in the lport.
> Maybe we should...

I thought of that, but it's less memory this way, and the tt only had
function pointers before.  Also, putting it there would require multiple
templates or modification of the existing template under a lock, or
setting this size to the largest that would ever be needed.  I think
we would end up modifying the template after it was copied to the lport
so I decided we might as well just modify it in the lport.  There are
other fields like this (offload capabilities).

> The dd_fcrport_size and dd_fcvport_size are members of the
> fc_function_template when dealing with the FC Transport.

That works OK there.

        Thanks,
        Joe




_______________________________________________
devel mailing list
[email protected]
http://www.open-fcoe.org/mailman/listinfo/devel

Reply via email to