On Tue, Oct 19, 2010 at 3:04 AM, Zou, Yi <yi.zou@xxxxxxxxx> wrote:
>>
>> There seems that skb_get could outlight skb_clone, if
>> retransmitting skb is the major concern.
>>
>> Signed-off-by: Hillf Danton <dhillf@xxxxxxxxx>
>> ---
>>
>> --- a/drivers/scsi/fcoe/fcoe.c    Â2010-09-13 07:07:38.000000000 +0800
>> +++ b/drivers/scsi/fcoe/fcoe.c    Â2010-10-17 20:03:08.000000000 +0800
>> @@ -1373,15 +1373,14 @@ err2:
>> Â */
>> Âstatic inline int fcoe_start_io(struct sk_buff *skb)
>> Â{
>> - Â Â struct sk_buff *nskb;
>> Â Â Â int rc;
>>
>> - Â Â nskb = skb_clone(skb, GFP_ATOMIC);
>> - Â Â rc = dev_queue_xmit(nskb);
>> - Â Â if (rc != 0)
>> + Â Â skb_get(skb); /* bump ref count for retransmitting */
>> + Â Â rc = dev_queue_xmit(skb);
>> + Â Â if (rc != NET_XMIT_SUCCESS)
>> Â Â Â Â Â Â Â return rc;
>> Â Â Â kfree_skb(skb);
>> - Â Â return 0;
>> + Â Â return NET_XMIT_SUCCESS;
>> Â}
>>
>> Â/**
>
> No, this was due to dev_queue_xmit not liking shared skb since
> __skb_linearize() would bug on, so we clone the skb here to be
> passed to dev_queue_xmit(), refer to the original commit id below
> for more details:
>
But the sg_supp related to hardware NIC seems already covered,
here is snippet from fc_fcp_send_data()
if (!fp) {
tlen = min(t_blen, remaining);
/*
* TODO. Temporary workaround. fc_seq_send() can't
* handle odd lengths in non-linear skbs.
* This will be the final fragment only.
*/
if (tlen % 4)
using_sg = 0;
fp = fc_frame_alloc(lport, using_sg ? 0 : tlen);
if (!fp)
return -ENOMEM;
data = fc_frame_header_get(fp) + 1;
fh_parm_offset = frame_offset;
fr_max_payload(fp) = fsp->max_payload;
}
and it seems little chance for hitting __skb_linearize.
> 18fa11efc279c20af5eefff2bbe814ca067e51ae
>
> Yi
>
>
--
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
