This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] RE: GPLPV: Respecting SG capability

To: "Russ Blaine" <russell.blaine@xxxxxxx>
Subject: [Xen-devel] RE: GPLPV: Respecting SG capability
From: "James Harper" <james.harper@xxxxxxxxxxxxxxxx>
Date: Tue, 28 Apr 2009 10:51:27 +1000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 27 Apr 2009 17:51:58 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <49F5FA5A.7060204@xxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <49F5FA5A.7060204@xxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcnHZ74bc3w5CwtURhCGONCNYsJijgAMz2Bg
Thread-topic: 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
> 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
> 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
> 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.
> 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
> 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
> 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.



Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>