| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
[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
|
|
|
| |
|
Home