kernel_sendpage query.

[rohan puri]

On Sat, Jun 9, 2012 at 8:26 PM, Pranay Kumar Srivastava <
Pranay.Shrivastava at hcl.com> wrote:

> Hi,
>
> I've been trying to understand kernel_sendpage but I've not been able to
> figure it out completely and hopefully someone else knows better so please
> help me out on this.
>
> I'm using kernel_sendpage for a TCP connection and it works well when
> there are lesser number of kernel threads trying to send data using it.
> Now the page I hand over to kernel_sendpage is reused again for reading
> data from the socket and then processing it and then again resending the
> processed data in the same page again. It's at maximum 2KB data and never
> lesser than 120 bytes.
>
> As I see it in the code, the page isn't copied in the skb frags array it's
> just assigned and get_page is called to increment the page reference count.
> (I don't free it anyway until the thread is stopped and it never is unless
> it gets a signal).
>
> Now I don't know wether kernel_sendpage will wait for the page to be sent
> or it won't. I've tried with MSG_DONTWAIT and passing 0 for flags but after
> every now and then the problem occurs at client which I'm describing below
> with the best explanation I could think of...
>
>        When too many kernel threads are trying to send data using
> kernel_sendpage, with NO MSG_DONTWAIT flag, then also it seems that this
> call succeeds? However since I'm reusing the page the data can get
> overridden by the next sock_recvmsg and when the network stack is ready to
> send my page it gets garbage data at client?
>
> The same issue I observed with MSG_DONTWAIT set even in that case the
> client sometimes get garbage data.
>
> So my query is,
>
> To use kernel_sendpage what I need to do in order to be sure that network
> stack indeed has sent my page and that I can reuse it for sock_recvmsg
> again.
>
> Thanks a lot for reading!
>
>
>
>
> Regards,
> Pranay Kr. Srivastava
> pranay.shrivastava at hcl.com
> Software Engineer
> ERS,HCL Technologies
> A-5, Sector 24, Noida 201301, U.P. (India)
>
>
>
> ::DISCLAIMER::
>
> ----------------------------------------------------------------------------------------------------------------------------------------------------
>
> The contents of this e-mail and any attachment(s) are confidential and
> intended for the named recipient(s) only.
> E-mail transmission is not guaranteed to be secure or error-free as
> information could be intercepted, corrupted,
> lost, destroyed, arrive late or incomplete, or may contain viruses in
> transmission. The e mail and its contents
> (with or without referred errors) shall therefore not attach any liability
> on the originator or HCL or its affiliates.
> Views or opinions, if any, presented in this email are solely those of the
> author and may not necessarily reflect the
> views or opinions of HCL or its affiliates. Any form of reproduction,
> dissemination, copying, disclosure, modification,
> distribution and / or publication of this message without the prior
> written consent of authorized representative of
> HCL is strictly prohibited. If you have received this email in error
> please delete it and notify the sender immediately.
> Before opening any email and/or attachments, please check them for viruses
> and other defects.
>
>
> ----------------------------------------------------------------------------------------------------------------------------------------------------
>
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>

Hi,

I had a brief look at the kernel_sendpage() function. It can call either
sock->ops->sendpage() if this is set or calls

sock_no_sendpage() otherwise. If sock_no_sendpage() code path is executed
then,

sock_no_sendpage() (kunmaps the page)-> kernel_sendmsg() -> sock_sendmsg()
(waits for data to be synced). So, I think you are OK if this is the code
path.

You need to check this in case of sock->ops->sendpage().

- Rohan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20120610/dfe22c11/attachment.html