Mike Christie wrote:
> Boaz Harrosh wrote:
> 
>>> +   if (!ddp) {
>>> +           ddp_log_warn("%s unable to alloc ddp 0x%d, ddp disabled.\n",
>>> +                        tdev->name, ppmax);
>>> +           return 0;
>>> +   }
>>> +   ddp->gl_map = (struct cxgb3i_gather_list **)(ddp + 1);
>>> +   ddp->gl_skb = (struct sk_buff **)(((char *)ddp->gl_map) +
>>> +                                     ppmax *
>>> +                                     sizeof(struct cxgb3i_gather_list *));
>>> +   spin_lock_init(&ddp->map_lock);
>>> +
>>> +   ddp->tdev = tdev;
>>> +   ddp->pdev = uinfo.pdev;
>>> +   ddp->max_txsz = min_t(unsigned int, uinfo.max_txsz, ULP2_MAX_PKT_SIZE);
>>> +   ddp->max_rxsz = min_t(unsigned int, uinfo.max_rxsz, ULP2_MAX_PKT_SIZE);
>> Please note that from what I understand, only the out-going headers can be
>> big, like iscsi_cmd header. But the in-coming headers are always 
>> size_of(struct iscsi_hdr).
>> So there is no symmetry here. Actually only iscsi_cmd can get big, the other 
>> out-going 
>> data packets are with small headers, but I guess that is an open-iscsi 
>> limitation.
>>
>> Mike correct me if I'm wrong?
> 
> Yeah, correct. Other iscsi pdus like tmfs and scsi data out could have 
> ahs but we do not support it. You did the code, so I assumed you only 
> did what you needed and could test.
> 
> On the recv side, I thought scsi cmd response or scsi data-in could have 
> ahses, but libiscsi_tcp/libiscsi just reads as much as it can in and 
> does not process it (actually it only reads in as much buffer space as 
> it has then fails if we overflow). I believe Olaf did this code to be 
> complete as he could with the existing code for the future, and to make 
> sure his abstraction would work for ahs if we needed it.

Yes you are right. I guess none of the targets send AHSs since otherwise
our initiator would fail on that particular packet.

It's time for me to go and look at why would a target send one.
It might be better to make a small enhancement and jump over
iscsi_hdr->hlength just throwing the data away, as a matter of error handling.
Better then failing the command completely.
That is if the AHS is just optional information.

I'll look into it.

Thanks
Boaz

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To post to this group, send email to open-iscsi@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~----------~----~----~----~------~----~------~--~---

Reply via email to