[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |