[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20091013015637.GB21809@ghostprotocols.net>
Date: Mon, 12 Oct 2009 22:56:37 -0300
From: Arnaldo Carvalho de Melo <acme@...stprotocols.net>
To: Nir Tzachar <nir.tzachar@...il.com>
Cc: David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
Caitlin Bestler <caitlin.bestler@...il.com>,
Chris Van Hoof <vanhoof@...hat.com>,
Clark Williams <williams@...hat.com>,
Neil Horman <nhorman@...driver.com>,
Nivedita Singhvi <niv@...ibm.com>,
Paul Moore <paul.moore@...com>,
RĂ©mi Denis-Courmont
<remi.denis-courmont@...ia.com>,
Steven Whitehouse <steve@...gwyn.com>
Subject: Re: [PATCH 1/1] net: Introduce recvmmsg socket syscall
Em Mon, Oct 12, 2009 at 07:53:43PM +0200, Nir Tzachar escreveu:
> Hi Arnaldo.
>
> Do you have any plans on how we can further investigate the delays I
> have seen with the second part of the patch? I have tried to simply
> unlock/lock the socket's mutex every couple of iterations inside the
Yeah, that is what tcp does, look at tcp_recvmsg (net/ipv4/tcp.c, line
1505), so I think we should do something along those lines, exactly when
and after which tests is a matter of experimentation.
I'll resume investigation tomorrow.
> loop (to allow the system to process some backlog), but this seems to
> have little to no effect.
> Also, a way to enable/disable the no_lock version at runtime will
> greatly help in testing. Maybe by first introducing a second syscall,
> recvmmsg_no_lock, for testing purposes??
I'll come up with a way for that to be possible.
- Arnaldo
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists