From: "Fabio M. De Francesco" <fmdefrancesco@gmail.com>
To: netdev@vger.kernel.org,
Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
Cc: Ira Weiny <ira.weiny@intel.com>,
Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>,
Ayush Sawal <ayush.sawal@chelsio.com>
Subject: Re: [PATCH v2 net-next 1/6] ch_ktls: Use memcpy_from_page() instead of k[un]map_atomic()
Date: Fri, 25 Nov 2022 16:34:35 +0100 [thread overview]
Message-ID: <5779845.MhkbZ0Pkbq@suse> (raw)
In-Reply-To: <20221123205219.31748-2-anirudh.venkataramanan@intel.com>
On mercoledì 23 novembre 2022 21:52:14 CET Anirudh Venkataramanan wrote:
> kmap_atomic() is being deprecated in favor of kmap_local_page(). Replace
> the map-memcpy-unmap usage pattern (done using k[un]map_atomic()) with
> memcpy_from_page(), which internally uses kmap_local_page() and
> kunmap_local(). This renders the variables 'data' and 'vaddr' unnecessary,
> and so remove these too.
>
> Note that kmap_atomic() disables preemption and page-fault processing, but
> kmap_local_page() doesn't. When converting uses of kmap_atomic(), one has
> to check if the code being executed between the map/unmap implicitly
> depends on page-faults and/or preemption being disabled. If yes, then code
> to disable page-faults and/or preemption should also be added for
> functional correctness. That however doesn't appear to be the case here,
> so just memcpy_from_page() is used.
Just two marginal notes:
It looks like you are explaining your mental process and teaching how
developers should approach these kinds of conversions. Although I'm OK with
this exposition, a plain assurance that the code being executed between the
map / unmap did not depend on page-faults and/or preemption being disabled
would have sufficed. :-)
Ira were suggesting to not use "it appears" and replace with stronger and
clearer assertions like "it is" or "I can confirm that" (or whatever else like
these).
As said, no problems at all with regard to the overall goodness of this and
the other patches.
>
> Also note that the page being mapped is not allocated by the driver, and so
> the driver doesn't know if the page is in normal memory. This is the reason
> kmap_local_page() is used (via memcpy_from_page()) as opposed to
> page_address().
>
> I don't have hardware, so this change has only been compile tested.
>
> Cc: Ayush Sawal <ayush.sawal@chelsio.com>
> Cc: Ira Weiny <ira.weiny@intel.com>
> Cc: Fabio M. De Francesco <fmdefrancesco@gmail.com>
> Suggested-by: Fabio M. De Francesco <fmdefrancesco@gmail.com>
> Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
> ---
> v1 -> v2:
> Use memcpy_from_page() as suggested by Fabio
> Add a "Suggested-by" tag
> Rework commit message
> Some emails cc'd in v1 are defunct. Drop them. The MAINTAINERS file for
> Chelsio drivers likely needs an update
> ---
> .../chelsio/inline_crypto/ch_ktls/chcr_ktls.c | 26 +++++++++----------
> 1 file changed, 12 insertions(+), 14 deletions(-)
It looks good to me.
Reviewed-by: Fabio M. De Francesco <fmdefrancesco@gmail.com>
Thanks,
Fabio
> diff --git a/drivers/net/ethernet/chelsio/inline_crypto/ch_ktls/chcr_ktls.c
> b/drivers/net/ethernet/chelsio/inline_crypto/ch_ktls/chcr_ktls.c index
> da9973b..1a5fdd7 100644
> --- a/drivers/net/ethernet/chelsio/inline_crypto/ch_ktls/chcr_ktls.c
> +++ b/drivers/net/ethernet/chelsio/inline_crypto/ch_ktls/chcr_ktls.c
> @@ -1839,9 +1839,7 @@ static int chcr_short_record_handler(struct
> chcr_ktls_info *tx_info, */
> if (prior_data_len) {
> int i = 0;
> - u8 *data = NULL;
> skb_frag_t *f;
> - u8 *vaddr;
> int frag_size = 0, frag_delta = 0;
>
> while (remaining > 0) {
> @@ -1853,24 +1851,24 @@ static int chcr_short_record_handler(struct
> chcr_ktls_info *tx_info, i++;
> }
> f = &record->frags[i];
> - vaddr = kmap_atomic(skb_frag_page(f));
> -
> - data = vaddr + skb_frag_off(f) + remaining;
> frag_delta = skb_frag_size(f) - remaining;
>
> if (frag_delta >= prior_data_len) {
> - memcpy(prior_data, data,
prior_data_len);
> - kunmap_atomic(vaddr);
> + memcpy_from_page(prior_data,
skb_frag_page(f),
> + skb_frag_off(f) +
remaining,
> + prior_data_len);
> } else {
> - memcpy(prior_data, data, frag_delta);
> - kunmap_atomic(vaddr);
> + memcpy_from_page(prior_data,
skb_frag_page(f),
> + skb_frag_off(f) +
remaining,
> + frag_delta);
> +
> /* get the next page */
> f = &record->frags[i + 1];
> - vaddr = kmap_atomic(skb_frag_page(f));
> - data = vaddr + skb_frag_off(f);
> - memcpy(prior_data + frag_delta,
> - data, (prior_data_len -
frag_delta));
> - kunmap_atomic(vaddr);
> +
> + memcpy_from_page(prior_data +
frag_delta,
> + skb_frag_page(f),
> + skb_frag_off(f),
> + prior_data_len -
frag_delta);
> }
> /* reset tcp_seq as per the prior_data_required
len */
> tcp_seq -= prior_data_len;
> --
> 2.37.2
next prev parent reply other threads:[~2022-11-25 15:34 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-23 20:52 [PATCH v2 net-next 0/6] Remove uses of kmap_atomic() Anirudh Venkataramanan
2022-11-23 20:52 ` [PATCH v2 net-next 1/6] ch_ktls: Use memcpy_from_page() instead of k[un]map_atomic() Anirudh Venkataramanan
2022-11-24 10:56 ` Ayush Sawal
2022-11-28 20:22 ` Anirudh Venkataramanan
2022-11-25 15:34 ` Fabio M. De Francesco [this message]
2022-11-23 20:52 ` [PATCH v2 net-next 2/6] sfc: Use kmap_local_page() instead of kmap_atomic() Anirudh Venkataramanan
2022-11-24 8:34 ` Martin Habets
2022-11-25 15:37 ` Fabio M. De Francesco
2022-11-23 20:52 ` [PATCH v2 net-next 3/6] cassini: Use page_address() " Anirudh Venkataramanan
2022-11-25 15:38 ` Fabio M. De Francesco
2022-11-23 20:52 ` [PATCH v2 net-next 4/6] cassini: Use memcpy_from_page() instead of k[un]map_atomic() Anirudh Venkataramanan
2022-11-25 15:39 ` Fabio M. De Francesco
2022-11-23 20:52 ` [PATCH v2 net-next 5/6] sunvnet: Use kmap_local_page() instead of kmap_atomic() Anirudh Venkataramanan
2022-11-25 15:40 ` Fabio M. De Francesco
2022-11-23 20:52 ` [PATCH v2 net-next 6/6] net: thunderbolt: " Anirudh Venkataramanan
2022-11-24 9:34 ` Mika Westerberg
2022-11-25 15:41 ` Fabio M. De Francesco
2022-11-25 10:50 ` [PATCH v2 net-next 0/6] Remove uses " patchwork-bot+netdevbpf
2022-11-25 15:47 ` Fabio M. De Francesco
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=5779845.MhkbZ0Pkbq@suse \
--to=fmdefrancesco@gmail.com \
--cc=anirudh.venkataramanan@intel.com \
--cc=ayush.sawal@chelsio.com \
--cc=ira.weiny@intel.com \
--cc=netdev@vger.kernel.org \
/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