From: Yunsheng Lin <linyunsheng@huawei.com>
To: Liang Chen <liangchen.linux@gmail.com>, <jasowang@redhat.com>,
<mst@redhat.com>
Cc: <virtualization@lists.linux-foundation.org>,
<netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<xuanzhuo@linux.alibaba.com>, <kuba@kernel.org>,
<edumazet@google.com>, <davem@davemloft.net>, <pabeni@redhat.com>,
<alexander.duyck@gmail.com>
Subject: Re: [PATCH net-next 3/5] virtio_net: Add page pool fragmentation support
Date: Mon, 29 May 2023 09:33:46 +0800 [thread overview]
Message-ID: <992eb402-43f9-0289-f95c-b41cb17f2e59@huawei.com> (raw)
In-Reply-To: <20230526054621.18371-3-liangchen.linux@gmail.com>
On 2023/5/26 13:46, Liang Chen wrote:
...
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 99c0ca0c1781..ac40b8c66c59 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -32,7 +32,9 @@ module_param(gso, bool, 0444);
> module_param(napi_tx, bool, 0644);
>
> static bool page_pool_enabled;
> +static bool page_pool_frag;
> module_param(page_pool_enabled, bool, 0400);
> +module_param(page_pool_frag, bool, 0400);
The below patchset unifies the frag and non-frag page for
page_pool_alloc_frag() API, perhaps it would simplify the
driver's support of page pool.
https://patchwork.kernel.org/project/netdevbpf/cover/20230526092616.40355-1-linyunsheng@huawei.com/
>
...
> @@ -1769,13 +1788,29 @@ static int add_recvbuf_mergeable(struct virtnet_info *vi,
> */
> len = get_mergeable_buf_len(rq, &rq->mrg_avg_pkt_len, room);
> if (rq->page_pool) {
> - struct page *page;
> + if (rq->page_pool->p.flags & PP_FLAG_PAGE_FRAG) {
> + if (unlikely(!page_pool_dev_alloc_frag(rq->page_pool,
> + &pp_frag_offset, len + room)))
> + return -ENOMEM;
> + buf = (char *)page_address(rq->page_pool->frag_page) +
> + pp_frag_offset;
> + buf += headroom; /* advance address leaving hole at front of pkt */
> + hole = (PAGE_SIZE << rq->page_pool->p.order)
> + - rq->page_pool->frag_offset;
> + if (hole < len + room) {
> + if (!headroom)
> + len += hole;
> + rq->page_pool->frag_offset += hole;
Is there any reason why the driver need to be aware of page_pool->frag_offset?
Isn't the page_pool_dev_alloc_frag() will drain the last page for you when
page_pool_dev_alloc_frag() is called with size being 'len + room' later?
One case I can think of needing this is to have an accurate truesize report
for skb, but I am not sure it matters that much as 'struct page_frag_cache'
and 'page_frag' implementation both have a similar problem.
> + }
> + } else {
> + struct page *page;
>
> - page = page_pool_dev_alloc_pages(rq->page_pool);
> - if (unlikely(!page))
> - return -ENOMEM;
> - buf = (char *)page_address(page);
> - buf += headroom; /* advance address leaving hole at front of pkt */
> + page = page_pool_dev_alloc_pages(rq->page_pool);
> + if (unlikely(!page))
> + return -ENOMEM;
> + buf = (char *)page_address(page);
> + buf += headroom; /* advance address leaving hole at front of pkt */
> + }
> } else {
> if (unlikely(!skb_page_frag_refill(len + room, alloc_frag, gfp)))
> return -ENOMEM;
> @@ -3800,13 +3835,16 @@ static void virtnet_alloc_page_pool(struct receive_queue *rq)
> struct virtio_device *vdev = rq->vq->vdev;
>
> struct page_pool_params pp_params = {
> - .order = 0,
> + .order = page_pool_frag ? SKB_FRAG_PAGE_ORDER : 0,
> .pool_size = rq->vq->num_max,
If it using order SKB_FRAG_PAGE_ORDER page, perhaps pool_size does
not have to be rq->vq->num_max? Even for order 0 page, perhaps the
pool_size does not need to be as big as rq->vq->num_max?
> .nid = dev_to_node(vdev->dev.parent),
> .dev = vdev->dev.parent,
> .offset = 0,
> };
>
> + if (page_pool_frag)
> + pp_params.flags |= PP_FLAG_PAGE_FRAG;
> +
> rq->page_pool = page_pool_create(&pp_params);
> if (IS_ERR(rq->page_pool)) {
> dev_warn(&vdev->dev, "page pool creation failed: %ld\n",
>
next prev parent reply other threads:[~2023-05-29 1:37 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-26 5:46 [PATCH net-next 1/5] virtio_net: Fix an unsafe reference to the page chain Liang Chen
2023-05-26 5:46 ` [PATCH net-next 2/5] virtio_net: Add page_pool support to improve performance Liang Chen
2023-05-26 6:50 ` Jason Wang
2023-05-27 12:35 ` Liang Chen
2023-05-28 6:40 ` Michael S. Tsirkin
2023-05-29 7:28 ` Liang Chen
2023-05-31 3:10 ` Xuan Zhuo
2023-06-07 9:11 ` Liang Chen
2023-06-07 9:33 ` Xuan Zhuo
2023-05-26 16:11 ` kernel test robot
2023-05-28 6:27 ` Michael S. Tsirkin
2023-05-29 7:28 ` Liang Chen
2023-05-28 6:20 ` Michael S. Tsirkin
2023-05-29 7:27 ` Liang Chen
2023-05-29 9:55 ` Michael S. Tsirkin
2023-05-30 1:19 ` Liang Chen
2023-06-07 9:08 ` Liang Chen
2023-06-07 9:35 ` Xuan Zhuo
2023-06-07 13:58 ` Liang Chen
2023-06-07 20:17 ` Michael S. Tsirkin
2023-06-08 0:38 ` Jason Wang
2023-06-08 3:54 ` Xuan Zhuo
2023-06-09 2:57 ` Liang Chen
2023-07-05 5:41 ` Liang Chen
2023-07-05 6:04 ` Jason Wang
2023-07-06 1:01 ` Liang Chen
2023-06-09 2:57 ` Liang Chen
2023-11-29 14:50 ` Zhu Yanjun
2023-11-29 14:59 ` Michael S. Tsirkin
2023-11-29 15:22 ` Zhu Yanjun
2023-11-29 15:29 ` Zhu Yanjun
2023-11-30 2:34 ` Xuan Zhuo
2023-11-30 5:30 ` Zhu Yanjun
2023-12-01 1:38 ` Xuan Zhuo
2023-12-04 5:24 ` Zhu Yanjun
2023-11-30 7:17 ` Zhu Yanjun
2023-05-26 5:46 ` [PATCH net-next 3/5] virtio_net: Add page pool fragmentation support Liang Chen
2023-05-26 8:29 ` Horatiu Vultur
2023-05-27 12:36 ` Liang Chen
2023-05-26 17:44 ` kernel test robot
2023-05-28 6:25 ` Michael S. Tsirkin
2023-05-29 7:29 ` Liang Chen
2023-05-29 1:33 ` Yunsheng Lin [this message]
2023-05-29 7:30 ` Liang Chen
2023-05-26 5:46 ` [PATCH net-next 4/5] virtio_ring: Introduce DMA pre-handler Liang Chen
2023-05-26 6:57 ` Jason Wang
2023-05-26 5:46 ` [PATCH net-next 5/5] virtio_net: Implement " Liang Chen
2023-05-26 7:06 ` Jason Wang
2023-05-27 12:35 ` Liang Chen
2023-05-26 17:34 ` kernel test robot
2023-05-26 6:38 ` [PATCH net-next 1/5] virtio_net: Fix an unsafe reference to the page chain Jason Wang
2023-05-27 12:33 ` Liang Chen
2023-05-28 6:29 ` Michael S. Tsirkin
2023-05-29 7:25 ` Liang Chen
2023-05-28 6:16 ` Michael S. Tsirkin
2023-05-29 7:25 ` Liang Chen
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=992eb402-43f9-0289-f95c-b41cb17f2e59@huawei.com \
--to=linyunsheng@huawei.com \
--cc=alexander.duyck@gmail.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=jasowang@redhat.com \
--cc=kuba@kernel.org \
--cc=liangchen.linux@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mst@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=virtualization@lists.linux-foundation.org \
--cc=xuanzhuo@linux.alibaba.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®