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
next prev parent 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: linkBe 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.