WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] GPLPV: Respecting SG capability

To: James Harper <james.harper@xxxxxxxxxxxxxxxx>
Subject: [Xen-devel] GPLPV: Respecting SG capability
From: Russ Blaine <russell.blaine@xxxxxxx>
Date: Mon, 27 Apr 2009 11:32:58 -0700
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 27 Apr 2009 11:48:21 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 2.0.0.17 (X11/20081023)
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.

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?

Here is the prototype of the fix.

 if (xi->config_sg == 0) {
      int i;
      ULONG len;
      ULONG offset = 0;
      PNDIS_BUFFER buf;

      buf = pi.first_buffer;
      while (buf) {
          PUCHAR src_addr;

          NdisQueryBufferSafe(buf, &src_addr, &len, NormalPagePriority);

          memcpy((PUCHAR)xi->tx_sendbuf.virtual + offset, src_addr, len);
          offset += len;

          NdisGetNextBuffer(buf, &buf);
      }

tx0->gref = (grant_ref_t)xi->tx_sendbuf.logical.QuadPart >> PAGE_SHIFT; tx0->offset = (USHORT)xi->tx_sendbuf.logical.LowPart & (PAGE_SIZE - 1);
      ASSERT(offset == pi.total_length);
      tx0->size = offset;
      tx0->flags &= ~NETTXF_more_data;
      sg_element = sg->NumberOfElements;
  } else if (header_buf)

Cheers,
- Russ

-----------------------------------------------------
Russ Blaine | Solaris Kernel | russell.blaine@xxxxxxx

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

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