Thread (16 messages) 16 messages, 8 authors, 2012-09-09

Re: [PATCH v2] net-tcp: TCP/IP stack bypass for loopback connections

flat view

From: Bruce Curtis <hidden>
Date: 2012-08-14 21:45:11

On Tue, Aug 14, 2012 at 2:22 PM, David Miller [off-list ref] wrote:
Bruce, could you integrate (and unlike your submission, actually build
and run test) Weiping's bug fixes?

Actually, I'm actually a little bit alarmed at Weiping's fixes,
because it makes it look as if you didn't test things at all under
net-next, as it appears that without his fixes any loopback TCP
connection would OOPS the kernel.
??? rebase, build, boot a dev machine, run several hours of testing,
take numbers from test and updated commit message (commit message test
results changed from patch to patch submit because of this) so ???
In fact, it wouldn't even build without the sysctl_tcp_friends typo.
Indeed:

net/ipv4/tcp.c: In function ‘tcp_recvmsg’:
net/ipv4/tcp.c:1935:35: error: ‘friends’ undeclared (first use in this function)
net/ipv4/tcp.c:1935:35: note: each undeclared identifier is reported only once for each function it appears in
Didn't build with CONFIG_NET_DMA and wasn't caught as part of
rebase/local var name change.
I hope I don't need to tell you how unacceptable this is.

That also means that all of your measurements in the commit message
weren't even made in the context where this patch will be applied.

Also unacceptable.
I stand by my numbers!!!
All of this makes for an extremely poor quality submission, please
correct these issues.
Looking into Weiping's bug, can't simple use
lock_sock()/release_sock() due to A<>B locking issues (i.e.
bi-directional socket I/O).
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help