Hi Jasen,
Do you know who is most intimate with the network packet capture using
mmap? I've been using Alexey's mods to libpcap which provide the ability
to set up a shared memory ring buffer. Back in the 2.2.x days I had
a problem which manifested itself only when a packet capture system (NFR)
would fork off processes. If I had initialized the ring buffer prior to
this time, then a child process would walk off with the memory leaving
the pcap capture loop to do just that forever on a very tight poll, wake
up you got something to do, opps no I don't, back to poll, forever.
By moving the initialization code for pcap to the very end of the main line
set up in the nfrd, it was able to limp along, and is still doing so to
this day. As long as I don't use any of the features which can cause the
deamon to spawn another child process, my shared memory stays intact.
But that's 2.2.x. Now I've got a similar libpcap which uses PACKET_RX_RING.
It does something like this on setup:
...
if (setsockopt(p->fd, SOL_PACKET, PACKET_RX_RING,
(void*)&req, sizeof(req))) {
perror("Warning: setsockopt(PACKET_RX_RING)");
return -1;
}
p->md.ringbuf = mmap(0, pgs*pg_size, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_SHARED, p->fd, 0);
...
With a single cpu non-smp kernel. Everything is hunky-dory. Initially,
when I went to SMP (dual cpu) I had problems with this using the fddi. I
thought it might just be the fddi driver. Although I cannot say for certain,
I did see the same "freeze" (or tight poll/check loop) with a gige interface.
Unfortunately, load seems to be a factor, and the router folks here are
having a time getting the gige to our Internet provider (ESnet) working. So,
I just see a little traffic. On the fddi, at around 50% utilization, after
about 300,000 packets the shared memory appeared to go away like in
the 2.2.x days. (I had put code in to test for that very problem back then,
and it came into play with 2.4.x.). But this time, it is not related to
child processes running off with my mmap'd memory. tcpdump hangs up, and
it doesn't do any funny stuff with fork's.
Does any of this ring a bell?
On Wed, Apr 11, 2001 at 02:18:31PM -0400, Jason Lunz wrote:
> On Wed, Apr 11, 2001 at 6:44PM +0200, Andi Kleen wrote:
> > If you don't need receiving on the local box you could also do it via
> > ethertap device or packet socket on dummy device, and then reinject into the
> > network. It'll not work for local packets though, because the routing
> > code does not allow to route locally destined packets somewhere else.
>
> You'd still have a speed problem as well. Depending on what you're
> doing, that's two copy_(to|from)_users of the entire packet. Being able
> to combine raw packet filtering with the speed of mmapped packet sockets
> seems a good way to do this quickly, especially if you don't need to
> filter on the entire packet.
>
> I'm still not sure why it locks up on SMP at gigabit ethernet speeds,
> though.
>
> --
> Jason Lunz Trellis Network Security
> j@trellisinc.com http://www.trellisinc.com/
> -
> : send the line "unsubscribe linux-net" in
> the body of a message to majordomo@vger.kernel.org
--
Phil Wood, cpw@lanl.gov
On Wed, Apr 11, 2001 at 02:18:31PM -0400, Jason Lunz wrote:
> On Wed, Apr 11, 2001 at 6:44PM +0200, Andi Kleen wrote:
> > If you don't need receiving on the local box you could also do it via
> > ethertap device or packet socket on dummy device, and then reinject into the
> > network. It'll not work for local packets though, because the routing
> > code does not allow to route locally destined packets somewhere else.
>
> You'd still have a speed problem as well. Depending on what you're
> doing, that's two copy_(to|from)_users of the entire packet. Being able
> to combine raw packet filtering with the speed of mmapped packet sockets
> seems a good way to do this quickly, especially if you don't need to
> filter on the entire packet.
>
> I'm still not sure why it locks up on SMP at gigabit ethernet speeds,
> though.
>
> --
> Jason Lunz Trellis Network Security
> j@trellisinc.com http://www.trellisinc.com/
> -
> : send the line "unsubscribe linux-net" in
> the body of a message to majordomo@vger.kernel.org
--
Phil Wood, cpw@lanl.gov
-
: send the line "unsubscribe linux-net" in
the body of a message to majordomo@vger.kernel.org
