All of lore.kernel.org
 help / color / mirror / Atom feed
From: Russ Blaine <russell.blaine@sun.com>
To: James Harper <james.harper@bendigoit.com.au>
Cc: xen-devel@lists.xensource.com
Subject: GPLPV: Respecting SG capability
Date: Mon, 27 Apr 2009 11:32:58 -0700	[thread overview]
Message-ID: <49F5FA5A.7060204@sun.com> (raw)

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@sun.com

             reply	other threads:[~2009-04-27 18:32 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-27 18:32 Russ Blaine [this message]
2009-04-28  0:51 ` GPLPV: Respecting SG capability James Harper
2009-06-18 22:31   ` Russ Blaine
2009-06-19 10:53     ` James Harper
2009-06-19 12:39     ` James Harper
2009-06-19 12:45       ` David Edmondson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=49F5FA5A.7060204@sun.com \
    --to=russell.blaine@sun.com \
    --cc=james.harper@bendigoit.com.au \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.