From: Robert Jarzmik <robert.jarzmik@free.fr>
To: Baolin Wang <baolin.wang@linaro.org>
Cc: Herbert Xu <herbert@gondor.apana.org.au>,
David Miller <davem@davemloft.net>,
Alasdair G Kergon <agk@redhat.com>,
Mike Snitzer <snitzer@redhat.com>,
axboe@fb.com, dm-devel@redhat.com, akpm@linux-foundation.org,
david.s.gordon@intel.com, Tom Lendacky <thomas.lendacky@amd.com>,
yamada.masahiro@socionext.com, smueller@chronox.de,
tadeusz.struk@intel.com, standby24x7@gmail.com, shli@kernel.org,
Mark Brown <broonie@kernel.org>,
Linus Walleij <linus.walleij@linaro.org>,
Arnd Bergmann <arnd@arndb.de>,
LKML <linux-kernel@vger.kernel.org>,
linux-crypto@vger.kernel.org, linux-raid@vger.kernel.org
Subject: Re: [PATCH 1/4] scatterlist: Introduce some helper functions
Date: Thu, 10 Mar 2016 10:42:12 +0100 [thread overview]
Message-ID: <87vb4ufz4b.fsf@belgarion.home> (raw)
In-Reply-To: <CAMz4kuKtwCkgG-3GeCtfnAX5zN8MkwyVr2XVYzaV3Z6SFFcZww@mail.gmail.com> (Baolin Wang's message of "Fri, 4 Mar 2016 14:29:25 +0800")
Baolin Wang <baolin.wang@linaro.org> writes:
> Hi Robert,
>
> On 4 March 2016 at 03:15, Robert Jarzmik <robert.jarzmik@free.fr> wrote:
>> Baolin Wang <baolin.wang@linaro.org> writes:
>>> +static inline bool sg_is_contiguous(struct scatterlist *sga,
>>> + struct scatterlist *sgb)
>>> +{
>>> + return ((sga->page_link & ~0x3UL) + sga->offset + sga->length ==
>>> + (sgb->page_link & ~0x3UL));
>>> +}
>> I don't understand that one.
>> sga->page_link is a pointer to a "struct page *". How can it be added to an
>> offset within a page ???
>
>
> Ah, sorry that's a mistake. It should check as below:
> static inline bool sg_is_contiguous(struct scatterlist *sga, struct
> scatterlist *sgb)
> {
> return (unsigned int)sg_virt(sga) + sga->length == (unsigned
> int)sg_virt(sgb);
> }
NAK.
First, I don't like the cast.
Second ask yourself: what if you compile on a 64 bit architecture ?
Third, I don't like void* arithmetics, some compilers might refuse it.
And as a last comment, is it "virtual" contiguity you're looking after, physical
contiguity, or dma_addr_t contiguity ?
>>> @@ -370,6 +370,65 @@ int sg_alloc_table(struct sg_table *table, unsigned int
>>> nents, gfp_t gfp_mask)
>> ...
>>> /**
>>> + * sg_add_sg_to_table - Add one scatterlist into sg table
>>> + * @sgt: The sg table header to use
>>> + * @src: The sg need to be added into sg table
>>> + *
>>> + * Description:
>>> + * The 'nents' member indicates how many scatterlists added in the sg table.
>>> + * Copy the @src@ scatterlist into sg table and increase 'nents' member.
>>> + *
>>> + **/
>>> +int sg_add_sg_to_table(struct sg_table *sgt, struct scatterlist *src)
>>> +{
>>> + unsigned int i = 0, orig_nents = sgt->orig_nents;
>>> + struct scatterlist *sgl = sgt->sgl;
>>> + struct scatterlist *sg;
>>> +
>>> + /* Check if there are enough space for the new sg to be added */
>>> + if (sgt->nents >= sgt->orig_nents)
>>> + return -EINVAL;
>> I must admit I don't understand that one either : how do comparing the number of
>> "mapped" entries against the number of "allocated" entries determines if there
>> is enough room ?
>
> That's for a dynamic sg table. If there is one sg table allocated
> 'orig_nents' scatterlists, and we need copy another mapped scatterlist
> into the sg table if there are some requirements. So we use 'nents' to
> record how many scatterlists have been copied into the sg table.
As I'm still having difficulities to understand, please explain to me :
- what is a dynamic sg_table
- how it works
- if it's "struct sg_table", how the field of this structure are different when
it's a dynamic sg_table from a "static sg_table" ?
>>> +/**
>>> + * sg_alloc_empty_table - Allocate one empty sg table
>>> + * @sgt: The sg table header to use
>>> + * @nents: Number of entries in sg list
>>> + * @gfp_mask: GFP allocation mask
>>> + *
>>> + * Description:
>>> + * Allocate and initialize an sg table. The 'nents' member of sg_table
>>> + * indicates how many scatterlists added in the sg table. It should set
>>> + * 0 which means there are no scatterlists added in this sg table now.
>>> + *
>>> + **/
>>> +int sg_alloc_empty_table(struct sg_table *sgt, unsigned int nents,
>>> + gfp_t gfp_mask)
>> As for this one, there has to be a purpose for it I fail to see. From far away
>> it looks exactly like sg_alloc_table(), excepting it "works around" the nents >
>> 0 protection of __sg_alloc_table().
>> What is exactly the need for this one, and if it's usefull why not simply
>> changing the __sg_alloc_table() "nents > 0" test and see what the outcome of the
>> review will be ?
>
> Like I said above. If we want to copy some mapped scatterlists into
> one sg table, we should set the 'nents' to 0 to indicates how many
> scatterlists coppied in the sg table.
So how do you unmap this scatterlist once you've lost the number of mapped
entries ?
I think we'll come back to this once I understand how a "dynamic" sg_table is
different from a "static" one.
Cheers.
--
Robert
next prev parent reply other threads:[~2016-03-10 9:42 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-03 5:19 [PATCH 0/4] Introduce bulk mode for crypto engine framework Baolin Wang
2016-03-03 5:19 ` [PATCH 1/4] scatterlist: Introduce some helper functions Baolin Wang
2016-03-03 19:15 ` Robert Jarzmik
2016-03-04 6:29 ` Baolin Wang
2016-03-04 6:53 ` Baolin Wang
2016-03-10 9:42 ` Robert Jarzmik [this message]
2016-03-10 12:58 ` Baolin Wang
2016-03-03 5:19 ` [PATCH 2/4] crypto: Introduce some helper functions to help to merge requests Baolin Wang
2016-03-03 5:19 ` [PATCH 3/4] crypto: Introduce the bulk mode for crypto engine framework Baolin Wang
2016-03-03 5:19 ` [PATCH 4/4] md: dm-crypt: Initialize the sector number for one request Baolin Wang
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=87vb4ufz4b.fsf@belgarion.home \
--to=robert.jarzmik@free.fr \
--cc=agk@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=axboe@fb.com \
--cc=baolin.wang@linaro.org \
--cc=broonie@kernel.org \
--cc=davem@davemloft.net \
--cc=david.s.gordon@intel.com \
--cc=dm-devel@redhat.com \
--cc=herbert@gondor.apana.org.au \
--cc=linus.walleij@linaro.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-raid@vger.kernel.org \
--cc=shli@kernel.org \
--cc=smueller@chronox.de \
--cc=snitzer@redhat.com \
--cc=standby24x7@gmail.com \
--cc=tadeusz.struk@intel.com \
--cc=thomas.lendacky@amd.com \
--cc=yamada.masahiro@socionext.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).