All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Steven Luong <sluong99@gmail.com>
Cc: john.fastabend@gmail.com, alexei.starovoitov@gmail.com,
	netdev@vger.kernel.org, virtio-dev@lists.oasis-open.org,
	virtualization@lists.linux-foundation.org, kvm@vger.kernel.org
Subject: Re: [virtio-dev] repost: af_packet vs virtio (was packed ring layout proposal v2)
Date: Wed, 2 Aug 2017 16:50:03 +0300	[thread overview]
Message-ID: <20170802164931-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <CAJR92jnV1VgBs567QNjO1fHKDgMX=1j1aJJ2gK-TqMB5E1=fvw@mail.gmail.com>

On Tue, Aug 01, 2017 at 08:54:27PM -0700, Steven Luong wrote:
>     * Descriptor ring:
> 
>     Guest adds descriptors with unique index values and DESC_HW set in flags.
>     Host overwrites used descriptors with correct len, index, and DESC_HW
>     clear.  Flags are always set/cleared last.
> 
>     #define DESC_HW 0x0080
> 
>     struct desc {
>             __le64 addr;
>             __le32 len;
>             __le16 index;
>             __le16 flags;
>     };
> 
>     When DESC_HW is set, descriptor belongs to device. When it is clear,
>     it belongs to the driver.
> 
>     We can use 1 bit to set direction
>     /* This marks a buffer as write-only (otherwise read-only). */
>     #define VRING_DESC_F_WRITE      2
> 
>     * Scatter/gather support
> 
>     We can use 1 bit to chain s/g entries in a request, same as virtio 1.0:
> 
>     /* This marks a buffer as continuing via the next field. */
> 
> 
> This comment here is confusing to me. In 1.0, virtq_desc has the next field.
> When the flag VRING_DESC_F_NEXT is set, the next entry to continue is specified
> in the next field.
> 
> Here in 1.1, struct desc does not have the next field, only addr, len, index,
> and flags. So when VRING_DESC_F_NEXT is set in struct desc's flags field, where
> is the next entry to continue the current descriptor, the entry immediately
> following the current entry? ie, if the current entry is at index 10 in the
> descriptor table and its flags is set for VRING_DESC_F_NEXT, is the entry
> continuing the current entry in index 11?
> 
> Steven

Exactly, you got it right.

---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org


WARNING: multiple messages have this Message-ID (diff)
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Steven Luong <sluong99@gmail.com>
Cc: john.fastabend@gmail.com, alexei.starovoitov@gmail.com,
	netdev@vger.kernel.org, virtio-dev@lists.oasis-open.org,
	virtualization@lists.linux-foundation.org, kvm@vger.kernel.org
Subject: Re: repost: af_packet vs virtio (was packed ring layout proposal v2)
Date: Wed, 2 Aug 2017 16:50:03 +0300	[thread overview]
Message-ID: <20170802164931-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <CAJR92jnV1VgBs567QNjO1fHKDgMX=1j1aJJ2gK-TqMB5E1=fvw@mail.gmail.com>

On Tue, Aug 01, 2017 at 08:54:27PM -0700, Steven Luong wrote:
>     * Descriptor ring:
> 
>     Guest adds descriptors with unique index values and DESC_HW set in flags.
>     Host overwrites used descriptors with correct len, index, and DESC_HW
>     clear.  Flags are always set/cleared last.
> 
>     #define DESC_HW 0x0080
> 
>     struct desc {
>             __le64 addr;
>             __le32 len;
>             __le16 index;
>             __le16 flags;
>     };
> 
>     When DESC_HW is set, descriptor belongs to device. When it is clear,
>     it belongs to the driver.
> 
>     We can use 1 bit to set direction
>     /* This marks a buffer as write-only (otherwise read-only). */
>     #define VRING_DESC_F_WRITE      2
> 
>     * Scatter/gather support
> 
>     We can use 1 bit to chain s/g entries in a request, same as virtio 1.0:
> 
>     /* This marks a buffer as continuing via the next field. */
> 
> 
> This comment here is confusing to me. In 1.0, virtq_desc has the next field.
> When the flag VRING_DESC_F_NEXT is set, the next entry to continue is specified
> in the next field.
> 
> Here in 1.1, struct desc does not have the next field, only addr, len, index,
> and flags. So when VRING_DESC_F_NEXT is set in struct desc's flags field, where
> is the next entry to continue the current descriptor, the entry immediately
> following the current entry? ie, if the current entry is at index 10 in the
> descriptor table and its flags is set for VRING_DESC_F_NEXT, is the entry
> continuing the current entry in index 11?
> 
> Steven

Exactly, you got it right.

  reply	other threads:[~2017-08-02 13:50 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-14  2:42 af_packet vs virtio Michael S. Tsirkin
2017-04-14  2:50 ` repost: af_packet vs virtio (was packed ring layout proposal v2) Michael S. Tsirkin
2017-08-02  3:54   ` [virtio-dev] " Steven Luong
2017-08-02  3:54   ` Steven Luong
2017-08-02  3:54     ` Steven Luong
2017-08-02 13:50     ` Michael S. Tsirkin [this message]
2017-08-02 13:50       ` Michael S. Tsirkin
2017-08-07  4:16       ` [virtio-dev] " Adam Tao
2017-08-07  4:16         ` Adam Tao
2017-08-07  4:16       ` [virtio-dev] " Adam Tao
2017-08-02 13:50     ` Michael S. Tsirkin
2017-04-14  2:50 ` Michael S. Tsirkin

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=20170802164931-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=alexei.starovoitov@gmail.com \
    --cc=john.fastabend@gmail.com \
    --cc=kvm@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=sluong99@gmail.com \
    --cc=virtio-dev@lists.oasis-open.org \
    --cc=virtualization@lists.linux-foundation.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.