> -----Original Message----- > From: netfilter-devel-owner@xxxxxxxxxxxxxxx [mailto:netfilter-devel- > owner@xxxxxxxxxxxxxxx] On Behalf Of Arif Hossain > Sent: Thursday, April 19, 2012 7:32 AM > To: netfilter@xxxxxxxxxxxxxxx; netfilter-devel@xxxxxxxxxxxxxxx > Subject: concatenate udp payloads of multiple packet > > Hi all. > > I have a netfilter_queue app which receives packets on a port range > and do modifications on them. Now i need to introduce to new features > with this basic app. > > First the traffic is quiet high. I have seen the --queue-balance > option. If i want to use it how should i approach? i mean should i > manage every queue from separate threads or > separate process to manage individual queues? I'm not sure how can i > use fork() to manage every queue separately. > > Secondly How packets are distributed among different queues? Based on > what property a packet is distributed? Any relationship i need to > know about > this distribution? > > Thirdly I need to concatenate udp payloads of several packet to > improve bandwidth usage. how should i approach this? The confusion is > when i stop finish processing > of one packet i call nfq_set_verdict() in nfq_callback(). My > confusion is when a packet popped from the NFQUEUE? when > nfq_set_verdict() returns or when nfq_callback() > returns? > > I mean if i push the incoming packets in user managed queues for > concatenation of udp payload(by this i will also drop individual > packets), then return from the nfq_callback(). > After processing in user managed queues(concatenation is done) then i > will issue nfq_set_verdict(). Would that work? > > Thanks in advance. > > -- > -aft I'm not an expert in this interface, but what I've observed is when user space reads a packet off of a socket to an NFQUEUE, a subsequent read on that socket will block if the first packet is not returned via nfq_set_verdict(), even if further packets have been queued from the kernel. So I don't think you can expect to read a bunch of packets, concatenate them and then return verdicts on them. You'd never see packets past the first one. At least that's what I have observed. I haven't dug into the kernel code to see if that is expected behavior. I had written an application which poll()'ed on two fds; one a socket to an NFQUEUE and another from signalfd() to SIGUSR1. The "handler" code for the SIGUSR1 signal fd just printf()'ed some statistics maintained by the application. Funny thing was, if ever my application failed to call nfq_set_verdict() for a packet read off of the socket, then poll() wouldn't return even when I sent the application a SIGUSR1 via kill. Not sure what was going on there. Good luck, Jeff Haran -- 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
