On Sat, Jun 9, 2012 at 8:26 PM, Pranay Kumar Srivastava < [email protected]> 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 > [email protected] > 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 > [email protected] > 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
_______________________________________________ Kernelnewbies mailing list [email protected] http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
