[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] RE: GPLPV: Respecting SG capability
> > Hi James, > > As you may have heard, the latest GPLPV release doesn't work on > Opensolaris dom0. Our backend net driver doesn't support scatter/gather, > but it seems that GPLPV now requires it. Correct. Previously I was doing the coalescing already to work around the problem that Linux has a limit of 18 SG elements. > > I have a fix for this in the frontend which coalesces all NDIS buffers > into one ring transaction. With the fix, packets flow again. > > Once this is addressed I may go and implement SG in our backend anyway, > but I wanted to get this fix into the GPLPV source first to enable > networking on older and current dom0s. > > The fix as I have it now is around line 229 of xennet_tx.c (see below). > I think a further and necessary improvement on this would be to avoid > the construction of the header_buf() altogether in the no-sg case. There > is also only one tx_sendbuf per driver instance (it just points to > tx_hb[0]), and I suppose there should be several and that they should be > managed in the same way you deal with the tx_hb[] instances. > > Actually, on second look, there is a per-driver-instance tx_lock which > must act to serialize all transmits? In which case we only need a single > tx_sendbuf anyhow. Would Windows benefit from having a reentrant send > routine? The send path is definitely serialised. 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. Thanks James _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |