| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
RE: [Xen-devel] RE: GPLPV: Respecting SG capability
>
> James Harper wrote:
> > We may be able to simply tell Windows that we don't support SG and
it
> > may coalesce the buffers itself. I will do some testing of that
before I
> > consider other workarounds.
>
> As I understand it, this isn't possible to do - Windows insists on
handing us
> several buffers per packet.
Yes, you are right. If we don't support SG then windows still gives us a
string of buffers chained together.
>
> Attached is a patch against the current source - it would be helpful
to have
> this in the upstream source so that these drivers work out of the box
on
> Solaris
> dom0 (albeit with scatter/gather disabled in the frontend). A future
> improvement
> on this work will be to avoid constructing header_buf in this case,
but this
> gets things working well enough. Another piece of future work will be
to have
> the net driver disable sg if the backend doesn't have "feature-sg" set
to 1 in
> xenstore.
>
> I can do a push if so desired, just let me know.
>
Each header buffer is only 512 (TX_HEADER_BUFFER_SIZE) bytes long, so I
don't think your solution will work reliably.
I actually implement the DMA_ADAPTER interface that builds the SG list
for devices on the 'xen' bus (in xenpci_pdo.c). I provide the following
hooks via windows 'device extensions':
. need_virtual_address function - return true if we need the VA of the
mapped buffer instead of the physical address (for scsiport)
. get_alignment function - return the required buffer alignment (again,
for scsiport that needs sectors aligned to 512 byte boundaries. I just
allocate a bounce buffer if required)
. max_sg_elements - the maximum number of sg elements allowed. I fail
any attempt to build an SG list with more than this many breaks, and
Windows just goes back and coalesces the buffers itself and resubmits
the single coalesced buffer.
Unfortunately max_sg_elements is set at the driver level (eg way before
we set up NDIS and know if we support SG or not) and so isn't much use
to you at the moment... I didn't have the foresight to make it a
function. DMA_ADAPTER knows nothing about NDIS so we need to be able to
get the NDIS adapter context (xi) from the DEVICE_OBJECT, and I don't
know how to do that or if it's possible yet...
The function would look something like:
static ULONG
max_sg_elements(DEVICE_OBJECT device_object)
{
struct xennet_info *xi = SOME_MAGIC_FUNCTION(device_object);
if (xi->config_sg)
return 19; /* defined in Linux as a maximum SG size */
else
return 1; /* as in SG isn't supported */
}
James
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home