All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander Duyck <alexander.duyck@gmail.com>
To: Eric Dumazet <edumazet@google.com>
Cc: Maciej Fijalkowski <maciej.fijalkowski@intel.com>,
	"Fabio M. De Francesco" <fmdefrancesco@gmail.com>,
	Jesper Dangaard Brouer <hawk@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	intel-wired-lan <intel-wired-lan@lists.osuosl.org>,
	Alexander Duyck <alexanderduyck@fb.com>,
	John Fastabend <john.fastabend@gmail.com>,
	Jesse Brandeburg <jesse.brandeburg@intel.com>,
	Alexei Starovoitov <ast@kernel.org>,
	Netdev <netdev@vger.kernel.org>, Jakub Kicinski <kuba@kernel.org>,
	bpf <bpf@vger.kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Ira Weiny <ira.weiny@intel.com>,
	"David S. Miller" <davem@davemloft.net>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [Intel-wired-lan] [PATCH] ixgbe: Use kmap_local_page in ixgbe_check_lbtest_frame()
Date: Thu, 30 Jun 2022 09:09:18 -0700	[thread overview]
Message-ID: <CAKgT0UcKRJUJrpFHdNrdH98eu_dpiZiVakJRqc2qHrdGJJQRQA@mail.gmail.com> (raw)
In-Reply-To: <CANn89iK6g+4Fy2VMV7=feUAOUDHu-J38be+oU76yp+zGH6xCJQ@mail.gmail.com>

On Thu, Jun 30, 2022 at 8:25 AM Eric Dumazet <edumazet@google.com> wrote:
>
> On Thu, Jun 30, 2022 at 5:17 PM Alexander Duyck
> <alexander.duyck@gmail.com> wrote:
> >
> > On Thu, Jun 30, 2022 at 3:10 AM Maciej Fijalkowski
> > <maciej.fijalkowski@intel.com> wrote:
> > >
> > > On Wed, Jun 29, 2022 at 10:58:36AM +0200, Fabio M. De Francesco wrote:
> > > > The use of kmap() is being deprecated in favor of kmap_local_page().
> > > >
> > > > With kmap_local_page(), the mapping is per thread, CPU local and not
> > > > globally visible. Furthermore, the mapping can be acquired from any context
> > > > (including interrupts).
> > > >
> > > > Therefore, use kmap_local_page() in ixgbe_check_lbtest_frame() because
> > > > this mapping is per thread, CPU local, and not globally visible.
> > >
> > > Hi,
> > >
> > > I'd like to ask why kmap was there in the first place and not plain
> > > page_address() ?
> > >
> > > Alex?
> >
> > The page_address function only works on architectures that have access
> > to all of physical memory via virtual memory addresses. The kmap
> > function is meant to take care of highmem which will need to be mapped
> > before it can be accessed.
> >
> > For non-highmem pages kmap just calls the page_address function.
> > https://elixir.bootlin.com/linux/latest/source/include/linux/highmem-internal.h#L40
>
>
> Sure, but drivers/net/ethernet/intel/ixgbe/ixgbe_main.c is allocating
> pages that are not highmem ?
>
> This kmap() does not seem needed.

Good point. So odds are page_address is fine to use. Actually there is
a note to that effect in ixgbe_pull_tail.

As such we could probably go through and update igb, and several of
the other Intel drivers as well.

- Alex

WARNING: multiple messages have this Message-ID (diff)
From: Alexander Duyck <alexander.duyck@gmail.com>
To: Eric Dumazet <edumazet@google.com>
Cc: Jesper Dangaard Brouer <hawk@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	"David S. Miller" <davem@davemloft.net>,
	Netdev <netdev@vger.kernel.org>,
	Alexander Duyck <alexanderduyck@fb.com>,
	John Fastabend <john.fastabend@gmail.com>,
	Jesse Brandeburg <jesse.brandeburg@intel.com>,
	Alexei Starovoitov <ast@kernel.org>,
	intel-wired-lan <intel-wired-lan@lists.osuosl.org>,
	Jakub Kicinski <kuba@kernel.org>, bpf <bpf@vger.kernel.org>,
	Paolo Abeni <pabeni@redhat.com>,
	"Fabio M. De Francesco" <fmdefrancesco@gmail.com>,
	Ira Weiny <ira.weiny@intel.com>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [Intel-wired-lan] [PATCH] ixgbe: Use kmap_local_page in ixgbe_check_lbtest_frame()
Date: Thu, 30 Jun 2022 09:09:18 -0700	[thread overview]
Message-ID: <CAKgT0UcKRJUJrpFHdNrdH98eu_dpiZiVakJRqc2qHrdGJJQRQA@mail.gmail.com> (raw)
In-Reply-To: <CANn89iK6g+4Fy2VMV7=feUAOUDHu-J38be+oU76yp+zGH6xCJQ@mail.gmail.com>

On Thu, Jun 30, 2022 at 8:25 AM Eric Dumazet <edumazet@google.com> wrote:
>
> On Thu, Jun 30, 2022 at 5:17 PM Alexander Duyck
> <alexander.duyck@gmail.com> wrote:
> >
> > On Thu, Jun 30, 2022 at 3:10 AM Maciej Fijalkowski
> > <maciej.fijalkowski@intel.com> wrote:
> > >
> > > On Wed, Jun 29, 2022 at 10:58:36AM +0200, Fabio M. De Francesco wrote:
> > > > The use of kmap() is being deprecated in favor of kmap_local_page().
> > > >
> > > > With kmap_local_page(), the mapping is per thread, CPU local and not
> > > > globally visible. Furthermore, the mapping can be acquired from any context
> > > > (including interrupts).
> > > >
> > > > Therefore, use kmap_local_page() in ixgbe_check_lbtest_frame() because
> > > > this mapping is per thread, CPU local, and not globally visible.
> > >
> > > Hi,
> > >
> > > I'd like to ask why kmap was there in the first place and not plain
> > > page_address() ?
> > >
> > > Alex?
> >
> > The page_address function only works on architectures that have access
> > to all of physical memory via virtual memory addresses. The kmap
> > function is meant to take care of highmem which will need to be mapped
> > before it can be accessed.
> >
> > For non-highmem pages kmap just calls the page_address function.
> > https://elixir.bootlin.com/linux/latest/source/include/linux/highmem-internal.h#L40
>
>
> Sure, but drivers/net/ethernet/intel/ixgbe/ixgbe_main.c is allocating
> pages that are not highmem ?
>
> This kmap() does not seem needed.

Good point. So odds are page_address is fine to use. Actually there is
a note to that effect in ixgbe_pull_tail.

As such we could probably go through and update igb, and several of
the other Intel drivers as well.

- Alex
_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan

  reply	other threads:[~2022-06-30 16:09 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-29  8:58 [PATCH] ixgbe: Use kmap_local_page in ixgbe_check_lbtest_frame() Fabio M. De Francesco
2022-06-29  8:58 ` [Intel-wired-lan] " Fabio M. De Francesco
2022-06-30 10:10 ` Maciej Fijalkowski
2022-06-30 10:10   ` [Intel-wired-lan] " Maciej Fijalkowski
2022-06-30 15:17   ` Alexander Duyck
2022-06-30 15:17     ` Alexander Duyck
2022-06-30 15:21     ` Maciej Fijalkowski
2022-06-30 15:21       ` Maciej Fijalkowski
2022-06-30 15:25     ` Eric Dumazet
2022-06-30 15:25       ` Eric Dumazet
2022-06-30 16:09       ` Alexander Duyck [this message]
2022-06-30 16:09         ` Alexander Duyck
2022-06-30 18:18         ` Fabio M. De Francesco
2022-06-30 18:18           ` Fabio M. De Francesco
2022-06-30 21:59           ` Alexander Duyck
2022-06-30 21:59             ` Alexander Duyck
2022-07-01 15:36             ` Fabio M. De Francesco
2022-07-01 15:36               ` Fabio M. De Francesco
2022-09-22 20:07               ` Anirudh Venkataramanan
2022-09-22 20:07                 ` Anirudh Venkataramanan
2022-09-22 20:58                 ` Alexander Duyck
2022-09-22 20:58                   ` Alexander Duyck
2022-09-22 22:38                   ` Anirudh Venkataramanan
2022-09-22 22:38                     ` Anirudh Venkataramanan
2022-09-23 15:05                     ` Fabio M. De Francesco
2022-09-23 15:05                       ` Fabio M. De Francesco
2022-09-23 17:59                       ` Anirudh Venkataramanan
2022-09-23 17:59                         ` Anirudh Venkataramanan
2022-09-30 22:03                       ` Fabio M. De Francesco
2022-09-30 22:03                         ` Fabio M. De Francesco
2022-09-23 15:31                     ` Alexander Duyck
2022-09-23 15:31                       ` Alexander Duyck
2022-09-23 18:50                       ` Anirudh Venkataramanan
2022-09-23 18:50                         ` Anirudh Venkataramanan
2022-09-23 21:31                         ` Alexander Duyck
2022-09-23 21:31                           ` Alexander Duyck
2022-06-30 18:13     ` Fabio M. De Francesco
2022-06-30 18:13       ` Fabio M. De Francesco
2022-08-04 12:53 ` G, GurucharanX
2022-08-04 12:53   ` G, GurucharanX

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=CAKgT0UcKRJUJrpFHdNrdH98eu_dpiZiVakJRqc2qHrdGJJQRQA@mail.gmail.com \
    --to=alexander.duyck@gmail.com \
    --cc=alexanderduyck@fb.com \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=fmdefrancesco@gmail.com \
    --cc=hawk@kernel.org \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=ira.weiny@intel.com \
    --cc=jesse.brandeburg@intel.com \
    --cc=john.fastabend@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maciej.fijalkowski@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 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.