Hi Yechiel, Thank you very much. I will try them. --peter 2010/10/2 Mistick Levi <gmistick@xxxxxxxxx>: > Hi, > > You could search some information about "NF_STOLEN" , but you'll have > to reinject the packet's later... and i don't have enough info about > that. > > and you could also change you're "recv loop" so that it wont execute > "handle_packet", but instead all it will do is queue the packet in > you're own queue... and continue extracting packets from the socket, > and you'll have a Âdifferent thread (hopefully on other cpu) that will > take that packet and execute "handle_packet"... > > a good documentation is: > http://www.netfilter.org/projects/libnetfilter_queue/doxygen/ > > > also, you asked before if you could increase the buffer space... you > can, with the network options of: wmem and rmem... google about it. > > Kind regards, > Yechiel Levi. > > On Fri, Oct 1, 2010 at 2:42 PM, Shihwei Li <lishihwei@xxxxxxxxx> wrote: >> Hi Yechiel, >> >> Thank you so much. Now I have a better understanding about the problem. >> >> Sorry for asking more questions, because it was not easy to find >> documents describing how the netfilter_queue works..There are still >> few things I am not clear about: >> >> * Verdicts: I am confused by the verdict and the return of the callback. >> >> Â From your description, I got the impression that I can issue >> verdict earlier in the callback, so even though the packet is still >> processed by the callback (i.e the callback() is not returned yet.), >> the kernel already can do something, say remove the packet out from >> the kernel buffer? >> > > NF_STOLEN, but it's not "returning the verdict earlier in the > callback", its finishing the callback... > >> ÂWhat is the relationship between the buffer space and verdict and >> their relationship to the callback? Can the kernel or the >> netfileter_queue do anything before the callback() returns? >> > > the buffer that is failing , is the buffer that is used to store the > packet's in "COPY_PACKET" mode. you extract messages from that buffer > by using the "recv" on the socket. > > the packet's still reside in the kernel queue.. ( which its size is > defined by the recv option or by set_queue_maxlen function) > > >> Â How do I do "save that message in you're own userspace queue and >> issue verdict later..."? Do you mean that I can take the packet and >> put it into my own queue in the userspace and return the callback w/o >> issuing any verdict? What does the kernel or the netfilter_queue do to >> a packet that is w/o a verdict? >> >> * What is the difference between queue_length and buffer space? Will >> the buffer space increase while the queue_lengh increases? >> >> >> --peter >> >> >> >> 2010/10/1 Mistick Levi <gmistick@xxxxxxxxx>: >>> Hi, >>> >>> the quick answer: >>> 1. don't die when you get "recv - failed" since it mean's you're >>> buffer is done, keep on the loop. >>> 2. don't do any heavy work on the callback. >>> 3. try to minimize I/O operations in you're callback, since they are >>> considered heavy, for example, writing to log will take "TONS" of >>> time... >>> >>> the "no buffer space available" issue is due to the program not >>> receiving packets fast enough and the allocated kernel buffer is >>> filling up with message's until you'll receive messages will keep on >>> dropping. >>> >>> what you should do is finish the callback function asap. >>> you could either: >>> Â1. issue verdict faster.. >>> 2. if you need to do some work on the packet before issue a verdict, >>> you could save that message in you're own userspace queue and issue >>> verdict later... >>> >>> the problem with the 2nd option is that now the "Queue length" of the >>> libnetfilter_queue will be filled... you could increase it too when >>> you initialize the queue, or when you with recv... >>> >>> Hope i've helped. >>> >>> Kind regards, >>> Yechiel Levi >>> >> > -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
