[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.