All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Ian Jackson <Ian.Jackson@citrix.com>,
	"Keir (Xen.org)" <keir@xen.org>, Jan Beulich <jbeulich@suse.com>,
	"Tim (Xen.org)" <tim@xen.org>
Subject: Re: [PATCH v4 1/3] public/io/netif.h: document transmit and receive wire formats separately
Date: Fri, 8 Jan 2016 15:56:58 +0000	[thread overview]
Message-ID: <e8f8ee97b87e40acb1fcabc9e28ec5a9@AMSPEX02CL03.citrite.net> (raw)
In-Reply-To: <1452266653.26438.4.camel@citrix.com>

> -----Original Message-----
[snip]
> >   * Guest transmit
> >   * ==============
> >   *
> > + * This is the 'wire' format for packets:
> > + *  Fragment 1: netif_tx_request_t  - flags = NETTXF_*
> > + *                                    size = total packet size
> > + * [Extra 1: netif_extra_info_t]    - (only if fragment 1 flags include
> > + *                                     NETTXF_extra_info)
> > + * [Extra N: netif_extra_info_t]    - (only if extra N-1 flags include
> > + *                                     XEN_NETIF_EXTRA_MORE)
> > + *  ...
> > + *  Fragment N: netif_tx_request_t  - (only if fragment N-1 flags include
> > + *                                     NETTXF_more_data)
> 
> For Fragment 2 is it the Flags of Fragment N-1 = 1 which are relevant, or
> the flags in the optional Extra N which may be in the middle (i.e. the
> immediately preceding slot)?

It's Fragment N-1's flags. The flags on the Extras are not relevant. In fact the only Extra flag defined is the one that says there's another Extra :-)

> 
> Am I correct in remembering that in the presence of NETTXF_more_data the
> only way to know the actual size of Fragment 1 is to take away the total of
> all the extras from Frag 1's size?

That's right.

> 
> > + *                                    flags = 0
> > + *                                    size = fragment size
> > + *
> >   * Ring slot size is 12 octets, however not all request/response
> >   * structs use the full size.
> >   *
> > @@ -202,6 +202,19 @@
> >   * Guest receive
> >   * =============
> >   *
> > + * This is the 'wire' format for packets:
> > + *  Fragment 1: netif_rx_request_t  - flags = NETRXF_*
> > + *                                    size = fragment size
> > + * [Extra 1: netif_extra_info_t]    - (only if fragment 1 flags include
> > + *                                     NETRXF_extra_info)
> > + * [Extra N: netif_extra_info_t]    - (only if extra N-1 flags include
> > + *                                     XEN_NETIF_EXTRA_MORE)
> > + *  ...
> > + *  Fragment N: netif_rx_request_t  - (only if fragment N-1 flags include
> > + *                                     NETRXF_more_data)
> > + *                                    flags = 0
> > + *                                    size = fragment size
> 
> Same Q re which NETRXF_more_data is relevant.
> 

Same answer :-)

> In this path there is no indication of the total packet size other than
> adding everything up?
> 

Correct. 

> Given that they differ in a subtle way would a quick but explicit "NOTE: RX
> and TX differ" be a useful addition do you think?
> 

Yes, that's probably a good plan. I'll stick an extra comment in to that effect.

  Paul

> > + *
> >   * Ring slot size is 8 octets.
> >   *
> >   * rx request (netif_rx_request_t)
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

  reply	other threads:[~2016-01-08 15:57 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-07 13:05 [PATCH v4 0/3] public/io/netif.h: support for toeplitz hashing Paul Durrant
2016-01-07 13:05 ` [PATCH v4 1/3] public/io/netif.h: document transmit and receive wire formats separately Paul Durrant
2016-01-08 15:24   ` Ian Campbell
2016-01-08 15:56     ` Paul Durrant [this message]
2016-01-08 16:10       ` Ian Campbell
2016-01-07 13:05 ` [PATCH v4 2/3] public/io/netif.h: document control ring and toeplitz hashing Paul Durrant
2016-01-08 15:53   ` Ian Campbell
2016-01-08 16:19     ` Paul Durrant
2016-01-08 16:46       ` Ian Campbell
2016-01-08 17:07         ` Paul Durrant
2016-01-08 17:22           ` Ian Campbell
2016-01-08 17:35             ` Paul Durrant
2016-01-08 16:07   ` David Vrabel
2016-01-08 16:21     ` Paul Durrant
2016-01-08 16:22       ` David Vrabel
2016-01-07 13:05 ` [PATCH v4 3/3] public/io/netif.h: document new extra info for passing hash values Paul Durrant
2016-01-08 16:05   ` Ian Campbell
2016-01-08 16:26     ` Paul Durrant
2016-01-08 16:48       ` Ian Campbell

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=e8f8ee97b87e40acb1fcabc9e28ec5a9@AMSPEX02CL03.citrite.net \
    --to=paul.durrant@citrix.com \
    --cc=Ian.Campbell@citrix.com \
    --cc=Ian.Jackson@citrix.com \
    --cc=jbeulich@suse.com \
    --cc=keir@xen.org \
    --cc=tim@xen.org \
    --cc=xen-devel@lists.xenproject.org \
    /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.