All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Abeni <pabeni@redhat.com>
To: Pavel Begunkov <asml.silence@gmail.com>, netdev@vger.kernel.org
Cc: "David S . Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>,
	linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org,
	Wei Liu <wei.liu@kernel.org>, Paul Durrant <paul@xen.org>,
	kvm@vger.kernel.org, virtualization@lists.linux-foundation.org,
	"Michael S . Tsirkin" <mst@redhat.com>,
	Jason Wang <jasowang@redhat.com>
Subject: Re: [PATCH net-next 0/4] shrink struct ubuf_info
Date: Tue, 27 Sep 2022 15:49:55 +0200	[thread overview]
Message-ID: <7fef56880d40b9d83cc99317df9060c4e7cdf919.camel@redhat.com> (raw)
In-Reply-To: <cover.1663892211.git.asml.silence@gmail.com>

Hello,

On Fri, 2022-09-23 at 17:39 +0100, Pavel Begunkov wrote:
> struct ubuf_info is large but not all fields are needed for all
> cases. We have limited space in io_uring for it and large ubuf_info
> prevents some struct embedding, even though we use only a subset
> of the fields. It's also not very clean trying to use this typeless
> extra space.
> 
> Shrink struct ubuf_info to only necessary fields used in generic paths,
> namely ->callback, ->refcnt and ->flags, which take only 16 bytes. And
> make MSG_ZEROCOPY and some other users to embed it into a larger struct
> ubuf_info_msgzc mimicking the former ubuf_info.
> 
> Note, xen/vhost may also have some cleaning on top by creating
> new structs containing ubuf_info but with proper types.

That sounds a bit scaring to me. If I read correctly, every uarg user
should check 'uarg->callback == msg_zerocopy_callback' before accessing
any 'extend' fields. AFAICS the current code sometimes don't do the
explicit test because the condition is somewhat implied, which in turn
is quite hard to track. 

clearing uarg->zerocopy for the 'wrong' uarg was armless and undetected
before this series, and after will trigger an oops..

There is some noise due to uarg -> uarg_zc renaming which make the
series harder to review. Have you considered instead keeping the old
name and introducing a smaller 'struct ubuf_info_common'? the overall
code should be mostly the same, but it will avoid the above mentioned
noise.

Thanks!

Paolo


WARNING: multiple messages have this Message-ID (diff)
From: Paolo Abeni <pabeni@redhat.com>
To: Pavel Begunkov <asml.silence@gmail.com>, netdev@vger.kernel.org
Cc: Wei Liu <wei.liu@kernel.org>,
	kvm@vger.kernel.org, Paul Durrant <paul@xen.org>,
	"Michael S . Tsirkin" <mst@redhat.com>,
	linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	xen-devel@lists.xenproject.org, Jakub Kicinski <kuba@kernel.org>,
	"David S . Miller" <davem@davemloft.net>
Subject: Re: [PATCH net-next 0/4] shrink struct ubuf_info
Date: Tue, 27 Sep 2022 15:49:55 +0200	[thread overview]
Message-ID: <7fef56880d40b9d83cc99317df9060c4e7cdf919.camel@redhat.com> (raw)
In-Reply-To: <cover.1663892211.git.asml.silence@gmail.com>

Hello,

On Fri, 2022-09-23 at 17:39 +0100, Pavel Begunkov wrote:
> struct ubuf_info is large but not all fields are needed for all
> cases. We have limited space in io_uring for it and large ubuf_info
> prevents some struct embedding, even though we use only a subset
> of the fields. It's also not very clean trying to use this typeless
> extra space.
> 
> Shrink struct ubuf_info to only necessary fields used in generic paths,
> namely ->callback, ->refcnt and ->flags, which take only 16 bytes. And
> make MSG_ZEROCOPY and some other users to embed it into a larger struct
> ubuf_info_msgzc mimicking the former ubuf_info.
> 
> Note, xen/vhost may also have some cleaning on top by creating
> new structs containing ubuf_info but with proper types.

That sounds a bit scaring to me. If I read correctly, every uarg user
should check 'uarg->callback == msg_zerocopy_callback' before accessing
any 'extend' fields. AFAICS the current code sometimes don't do the
explicit test because the condition is somewhat implied, which in turn
is quite hard to track. 

clearing uarg->zerocopy for the 'wrong' uarg was armless and undetected
before this series, and after will trigger an oops..

There is some noise due to uarg -> uarg_zc renaming which make the
series harder to review. Have you considered instead keeping the old
name and introducing a smaller 'struct ubuf_info_common'? the overall
code should be mostly the same, but it will avoid the above mentioned
noise.

Thanks!

Paolo

_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

  parent reply	other threads:[~2022-09-27 13:50 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-23 16:39 [PATCH net-next 0/4] shrink struct ubuf_info Pavel Begunkov
2022-09-23 16:39 ` [PATCH net-next 1/4] net: introduce struct ubuf_info_msgzc Pavel Begunkov
2022-09-23 16:39 ` [PATCH net-next 2/4] xen/netback: use " Pavel Begunkov
2022-09-23 16:39 ` [PATCH net-next 3/4] vhost/net: " Pavel Begunkov
2022-09-23 16:39 ` [PATCH net-next 4/4] net: shrink struct ubuf_info Pavel Begunkov
2022-09-27 13:49 ` Paolo Abeni [this message]
2022-09-27 13:49   ` [PATCH net-next 0/4] " Paolo Abeni
2022-09-27 14:28   ` Pavel Begunkov
2022-09-27 17:16     ` Pavel Begunkov
2022-09-27 17:56       ` Paolo Abeni
2022-09-27 17:56         ` Paolo Abeni
2022-09-27 18:48         ` Pavel Begunkov
2022-09-27 19:59           ` Paolo Abeni
2022-09-27 19:59             ` Paolo Abeni
2022-09-27 20:17             ` Pavel Begunkov
2022-09-27 20:23               ` Paolo Abeni
2022-09-27 20:23                 ` Paolo Abeni
2022-09-27 21:02                 ` Pavel Begunkov
2022-09-29  2:20 ` patchwork-bot+netdevbpf

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=7fef56880d40b9d83cc99317df9060c4e7cdf919.camel@redhat.com \
    --to=pabeni@redhat.com \
    --cc=asml.silence@gmail.com \
    --cc=davem@davemloft.net \
    --cc=jasowang@redhat.com \
    --cc=kuba@kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=paul@xen.org \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=wei.liu@kernel.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.