[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20080813.190706.251724821.davem@davemloft.net>
Date: Wed, 13 Aug 2008 19:07:06 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: tom@...ngridcomputing.com
Cc: rdreier@...co.com, rick.jones2@...com, jgarzik@...ox.com,
swise@...ngridcomputing.com, divy@...lsio.com, kxie@...lsio.com,
netdev@...r.kernel.org, open-iscsi@...glegroups.com,
michaelc@...wisc.edu, daisyc@...ibm.com, wenxiong@...ibm.com,
bhua@...ibm.com, dm@...lsio.com, leedom@...lsio.com,
linux-scsi@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC][PATCH 1/1] cxgb3i: cxgb3 iSCSI initiator
From: Tom Tucker <tom@...ngridcomputing.com>
Date: Wed, 13 Aug 2008 20:57:08 -0500
> I'm not trying to be pedantic here but let me try and restate what I
> think you said above:
>
> - The "header" traverses the real networking stack
> - The "payload" is placed either by by the hardware if possible or by
> the native stack if on the exception path
> - The "header" may aggregate multiple PDU (RSO)
> - Data ready indications are controlled entirely by the software/real
> networking stack
SKB's can be paged, in fact many devices already work by chopping
up lists of pages that the driver gives to the card. NIU is one
of several examples.
The only difference between what a device like NIU is doing now and
what I propose is smart determination of at what offset and into
which buffers to do the demarcation.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists