All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Fabio M. De Francesco" <fmdefrancesco@gmail.com>
To: Alexander Duyck <alexander.duyck@gmail.com>
Cc: Eric Dumazet <edumazet@google.com>,
	Maciej Fijalkowski <maciej.fijalkowski@intel.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: Fri, 01 Jul 2022 17:36:42 +0200	[thread overview]
Message-ID: <2834855.e9J7NaK4W3@opensuse> (raw)
In-Reply-To: <CAKgT0UfThk3MLcE38wQu5+2Qy7Ld2px-2WJgnD+2xbDsA8iEEw@mail.gmail.com>

On giovedì 30 giugno 2022 23:59:23 CEST Alexander Duyck wrote:
> On Thu, Jun 30, 2022 at 11:18 AM Fabio M. De Francesco
> <fmdefrancesco@gmail.com> wrote:
> >
> > On giovedì 30 giugno 2022 18:09:18 CEST Alexander Duyck wrote:
> > > 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
> > >
> > I don't know this code, however I know kmap*().
> >
> > I assumed that, if author used kmap(), there was possibility that the 
page
> > came from highmem.
> >
> > In that case kmap_local_page() looks correct here.
> >
> > However, now I read that that page _cannot_ come from highmem. 
Therefore,
> > page_address() would suffice.
> >
> > If you all want I can replace kmap() / kunmap() with a "plain"
> > page_address(). Please let me know.
> >
> > Thanks,
> >
> > Fabio
> 
> Replacing it with just page_address() should be fine. Back when I
> wrote the code I didn't realize that GFP_ATOMIC pages weren't
> allocated from highmem so I suspect I just used kmap since it was the
> way to cover all the bases.
> 
> Thanks,
> 
> - Alex
> 

OK, I'm about to prepare another patch with page_address() (obviously, this 
should be discarded).

Last thing... Is that page allocated with dma_pool_alloc() at
ixgbe/ixgbe_fcoe.c:196? Somewhere else?

Thanks,

Fabio

P.S.: Can you say something about how pages are allocated in intel/e1000 
and in intel/e1000e? I see that those drivers use kmap_atomic().




WARNING: multiple messages have this Message-ID (diff)
From: "Fabio M. De Francesco" <fmdefrancesco@gmail.com>
To: Alexander Duyck <alexander.duyck@gmail.com>
Cc: Jesper Dangaard Brouer <hawk@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.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>,
	Eric Dumazet <edumazet@google.com>,
	intel-wired-lan <intel-wired-lan@lists.osuosl.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: Fri, 01 Jul 2022 17:36:42 +0200	[thread overview]
Message-ID: <2834855.e9J7NaK4W3@opensuse> (raw)
In-Reply-To: <CAKgT0UfThk3MLcE38wQu5+2Qy7Ld2px-2WJgnD+2xbDsA8iEEw@mail.gmail.com>

On giovedì 30 giugno 2022 23:59:23 CEST Alexander Duyck wrote:
> On Thu, Jun 30, 2022 at 11:18 AM Fabio M. De Francesco
> <fmdefrancesco@gmail.com> wrote:
> >
> > On giovedì 30 giugno 2022 18:09:18 CEST Alexander Duyck wrote:
> > > 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
> > >
> > I don't know this code, however I know kmap*().
> >
> > I assumed that, if author used kmap(), there was possibility that the 
page
> > came from highmem.
> >
> > In that case kmap_local_page() looks correct here.
> >
> > However, now I read that that page _cannot_ come from highmem. 
Therefore,
> > page_address() would suffice.
> >
> > If you all want I can replace kmap() / kunmap() with a "plain"
> > page_address(). Please let me know.
> >
> > Thanks,
> >
> > Fabio
> 
> Replacing it with just page_address() should be fine. Back when I
> wrote the code I didn't realize that GFP_ATOMIC pages weren't
> allocated from highmem so I suspect I just used kmap since it was the
> way to cover all the bases.
> 
> Thanks,
> 
> - Alex
> 

OK, I'm about to prepare another patch with page_address() (obviously, this 
should be discarded).

Last thing... Is that page allocated with dma_pool_alloc() at
ixgbe/ixgbe_fcoe.c:196? Somewhere else?

Thanks,

Fabio

P.S.: Can you say something about how pages are allocated in intel/e1000 
and in intel/e1000e? I see that those drivers use kmap_atomic().



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

  reply	other threads:[~2022-07-01 15:37 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
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 [this message]
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=2834855.e9J7NaK4W3@opensuse \
    --to=fmdefrancesco@gmail.com \
    --cc=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=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.