bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kal Cutter Conley <kal.conley@dectris.com>
To: Magnus Karlsson <magnus.karlsson@gmail.com>
Cc: "Björn Töpel" <bjorn@kernel.org>,
	"Magnus Karlsson" <magnus.karlsson@intel.com>,
	"Maciej Fijalkowski" <maciej.fijalkowski@intel.com>,
	"Jonathan Lemon" <jonathan.lemon@gmail.com>,
	"David S. Miller" <davem@davemloft.net>,
	"Eric Dumazet" <edumazet@google.com>,
	"Jakub Kicinski" <kuba@kernel.org>,
	"Paolo Abeni" <pabeni@redhat.com>,
	"Jonathan Corbet" <corbet@lwn.net>,
	"Alexei Starovoitov" <ast@kernel.org>,
	"Daniel Borkmann" <daniel@iogearbox.net>,
	"Jesper Dangaard Brouer" <hawk@kernel.org>,
	"John Fastabend" <john.fastabend@gmail.com>,
	netdev@vger.kernel.org, bpf@vger.kernel.org,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH bpf-next v2 08/10] xsk: Support UMEM chunk_size > PAGE_SIZE
Date: Tue, 4 Apr 2023 12:33:58 +0200	[thread overview]
Message-ID: <CAHApi-=ui3JofMr7y+LvuYkXCU=h7vGiKXsfuV5gog-02u-u+Q@mail.gmail.com> (raw)
In-Reply-To: <CAJ8uoz0SEkcXQuoqYd94GreJqpCxQuf1QVgm9=Um6Wqk=s8GBw@mail.gmail.com>

> > > Is not the max 64K as you test against XDP_UMEM_MAX_CHUNK_SIZE in
> > > xdp_umem_reg()?
> >
> > The absolute max is 64K. In the case of HPAGE_SIZE < 64K, then it
> > would be HPAGE_SIZE.
>
> Is there such a case when HPAGE_SIZE would be less than 64K? If not,
> then just write 64K.

Yes. While most platforms have HPAGE_SIZE defined to a compile-time
constant >= 64K (very often 2M) there are platforms (at least ia64 and
powerpc) where the hugepage size is configured at boot. Specifically,
in the case of Itanium (ia64), the hugepage size may be configured at
boot to any valid page size > PAGE_SIZE (e.g. 8K). See:
https://elixir.bootlin.com/linux/latest/source/arch/ia64/mm/hugetlbpage.c#L159

>
> > > >  static int xdp_umem_pin_pages(struct xdp_umem *umem, unsigned long address)
> > > >  {
> > > > +#ifdef CONFIG_HUGETLB_PAGE
> > >
> > > Let us try to get rid of most of these #ifdefs sprinkled around the
> > > code. How about hiding this inside xdp_umem_is_hugetlb() and get rid
> > > of these #ifdefs below? Since I believe it is quite uncommon not to
> > > have this config enabled, we could simplify things by always using the
> > > page_size in the pool, for example. And dito for the one in struct
> > > xdp_umem. What do you think?
> >
> > I used #ifdef for `page_size` in the pool for maximum performance when
> > huge pages are disabled. We could also not worry about optimizing this
> > uncommon case though since the performance impact is very small.
> > However, I don't find the #ifdefs excessive either.
>
> Keep them to a minimum please since there are few of them in the
> current code outside of some header files. And let us assume that
> CONFIG_HUGETLB_PAGE is the common case.
>

Would you be OK if I just remove the ones from xsk_buff_pool? I think
the code in xdp_umem.c is quite readable and the #ifdefs are really
only used in xdp_umem_pin_pages.

  reply	other threads:[~2023-04-04 10:29 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-29 18:04 [PATCH bpf-next v2 00/10] xsk: Support UMEM chunk_size > PAGE_SIZE Kal Conley
2023-03-29 18:04 ` [PATCH bpf-next v2 01/10] selftests: xsk: Add xskxceiver.h dependency to Makefile Kal Conley
2023-03-29 18:04 ` [PATCH bpf-next v2 02/10] selftests: xsk: Use correct UMEM size in testapp_invalid_desc Kal Conley
2023-03-29 18:04 ` [PATCH bpf-next v2 03/10] selftests: xsk: Add test case for packets at end of UMEM Kal Conley
2023-03-29 18:04 ` [PATCH bpf-next v2 04/10] selftests: xsk: Deflakify STATS_RX_DROPPED test Kal Conley
2023-04-03 10:54   ` Magnus Karlsson
2023-04-03 11:06     ` Kal Cutter Conley
2023-04-03 11:40       ` Kal Cutter Conley
2023-04-03 11:38         ` Magnus Karlsson
2023-04-03 11:47           ` Kal Cutter Conley
2023-03-29 18:04 ` [PATCH bpf-next v2 05/10] selftests: xsk: Disable IPv6 on VETH1 Kal Conley
2023-03-29 18:04 ` [PATCH bpf-next v2 06/10] xsk: Add check for unaligned descriptors that overrun UMEM Kal Conley
2023-04-03 12:23   ` Magnus Karlsson
2023-04-03 12:50     ` Kal Cutter Conley
2023-03-29 18:04 ` [PATCH bpf-next v2 07/10] selftests: xsk: Add test UNALIGNED_INV_DESC_4K1_FRAME_SIZE Kal Conley
2023-04-03 12:25   ` Magnus Karlsson
2023-03-29 18:05 ` [PATCH bpf-next v2 08/10] xsk: Support UMEM chunk_size > PAGE_SIZE Kal Conley
2023-04-04  7:39   ` Magnus Karlsson
2023-04-04  8:20     ` Kal Cutter Conley
2023-04-04  9:29       ` Magnus Karlsson
2023-04-04 10:33         ` Kal Cutter Conley [this message]
2023-04-04 11:14           ` Magnus Karlsson
2023-04-04 12:18             ` Kal Cutter Conley
2023-04-04 12:37               ` Kal Cutter Conley
2023-04-04 12:54                 ` Magnus Karlsson
2023-03-29 18:05 ` [PATCH bpf-next v2 09/10] selftests: xsk: Use hugepages when umem->frame_size " Kal Conley
2023-03-29 18:05 ` [PATCH bpf-next v2 10/10] selftests: xsk: Add tests for 8K and 9K frame sizes Kal Conley

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='CAHApi-=ui3JofMr7y+LvuYkXCU=h7vGiKXsfuV5gog-02u-u+Q@mail.gmail.com' \
    --to=kal.conley@dectris.com \
    --cc=ast@kernel.org \
    --cc=bjorn@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=corbet@lwn.net \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=hawk@kernel.org \
    --cc=john.fastabend@gmail.com \
    --cc=jonathan.lemon@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maciej.fijalkowski@intel.com \
    --cc=magnus.karlsson@gmail.com \
    --cc=magnus.karlsson@intel.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.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;
as well as URLs for NNTP newsgroup(s).