Thread (8 messages) 8 messages, 3 authors, 2024-01-08

Re: [PATCH net-next 0/1] Introducing OpenVPN Data Channel Offload

From: Antonio Quartulli <antonio@openvpn.net>
Date: 2024-01-07 23:31:53

Hi Sergey,

Thanks for jumping in

On 06/01/2024 23:29, Sergey Ryazanov wrote:
Hi Antonio,

On 06.01.2024 23:57, Antonio Quartulli wrote:
quoted
I tend to agree that a unique large patch is harder to review, but
splitting the code into several paches proved to be quite cumbersome,
therefore I prefered to not do it. I believe the code can still be
reviewed file by file, despite in the same patch.
I am happy to know that project is ongoing. But I had stopped the review 
after reading these lines. You need AI to review at once "35 files 
changed, 5914 insertions(+)". Last time I checked, I was human. Sorry.

Or you can see it like this: if submitter does not care, then why anyone 
else should?
I am sorry - I did not mean to be careless/sloppy.

I totally understand, but I truly burnt so much time on finding a 
reasonable way to split this patch that I had to give up at some point.

I get your input, but do you think that turning it into 35 patches of 1 
file each (just as a random example), will make it easier to digest?

Anyway, I will give it another try (the test robot complained about 
something, so it seems I need to resend the patch anyway) and I'll see 
where I land.

Cheers!
quoted
** KNOWN ISSUE:
Upon module unloading something is not torn down correctly and sometimes
new packets hit dangling netdev pointers. This problem did not exist
when the RTNL API was implemented (before interface handling was moved
to Netlink). I was hoping to get some feedback from the netdev community
on anything that may look wrong.
A small hint, if the series is not going to be merged, then it is better 
to mark it as RFC.

-- 
Sergey
-- 
Antonio Quartulli
OpenVPN Inc.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help