[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <02d4971c-a906-44e8-b694-bd54a89cf671@gmail.com>
Date: Sat, 19 Oct 2024 16:27:03 +0800
From: Yunsheng Lin <yunshenglin0825@...il.com>
To: Alexander Duyck <alexander.duyck@...il.com>,
Yunsheng Lin <linyunsheng@...wei.com>, davem@...emloft.net, kuba@...nel.org,
Paolo Abeni <pabeni@...hat.com>
Cc: netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
Shuah Khan <skhan@...uxfoundation.org>, Eric Dumazet <edumazet@...gle.com>
Subject: Re: [PATCH net-next v22 00/14] Replace page_frag with page_frag_cache
for sk_page_frag()
On 10/19/2024 1:39 AM, Alexander Duyck wrote:
>>
>
> So I still think this set should be split in half in order to make
> this easier to review. The ones I have provided a review-by for so far
> seem fine to me. I really think if you just submitted that batch first
> we can get that landed and let them stew in the kernel for a bit to
> make sure we didn't miss anything there.
It makes sense to me too that it might be better to get those submitted
to get more testing if there is no more comment about it.
I am guessing they should be targetting net-next tree to get more
testing as all the callers of page_frag API seem to be in the
networking, right?
Hi, David, Jakub & Paolo
It would be good if those patches are just cherry-picked from this
patchset as those patches with 'Reviewed-by' tag seem to be applying
cleanly. Or any better suggestion here?
>
> As far as the others there is a bunch there for me to try and chew
> through. A bunch of that is stuff not related necessarily to my
> version of the page frag stuff that I did so merging the two is a bit
> less obvious to me. The one thing I am wondering about is the behavior
> for why we are pulling apart the logic with this "commit" approach
> that is deferring the offset update which seems to have to happen
> unless we need to abort.
Let's discuss that in patch 7.
>
> My review time is going to be limited for the next several weeks. As
> such I will likely not be able to get to a review until Friday or
> Saturday each week so sending out updates faster than that will not
> get you any additional reviews from me.
Thanks for the time reviewing and reminding about the above.
It makes sense to have more time to have more reviewing as long as we
are making productive progress.
>
> Thanks,
>
> - Alex
>
Powered by blists - more mailing lists