On Wed, Nov 28, 2012 at 12:43 PM, Reyk Floeter <[email protected]> wrote: > On Tue, Nov 27, 2012 at 10:17 PM, Mike Belopuhov <[email protected]> wrote: >> apparently it works just fine. the number of clones is limited >> by the v_specbitmap which currently allows for 64 clones total >> (per system, not per process). >> > > Please clarify: Does it mean 64 cloned bpf devices per system or 64 > cloned devices of any type in total? >
64 (or whatever we set the bitmask to be) cloned bpf devices per system. > Or would it even allow to use bpf0 for the first 64 clones, bpf1 for the > next 64 and so on? there's not supposed to be bpf0,1,2,3... it's supposed to be just /dev/bpf with a minor of 0. but pcap and other programs will need to be adjusted for that (upstream pcap already has code for that, and naturally it's not complicated at all). > If running a custom kernel (according to the diff in your next email) > is the only way to increase this limit, I would propose to bump the > default to at least 256. I know of at least a few people who run many > interfaces/VLANs (> 64) and need one bpf per interface. > it's safe to bump it to 1024. that bitmask (and the structure itself) is allocated once per character device (i.e. one bitmask for drm, one for bpf -- two chunks of memory in total). >> apply the diff and see how all your apps are happily using single >> device node: /dev/bpf0. >> >> thanks to pedro and thib for the spec_open_clone and guenther >> for helping out big time. >> >> i'm not 100% sure we want this but why wouldn't we? >> generally speaking we also need to move to a single /dev/bpf >> node, but that can be done, once this diff is tested and we all >> agree that this is a way to go. >> >> so please test and share your thoughts. >> > > I want this. Actually I want this for a long time (about 6 years?). > But I cannot judge the fs layer of the implementation. > > At least NetBSD, FreeBSD, DragonFlyBSD and Solaris seem to have a > clonable /dev/bpf for a long time now. Going to a single /dev/bpf > shouldn't be a big problem as we can update our in-tree bpf users > easily, most ports including snort/daq seem to use our libpcap, and > other upstream code already checks for a clonable /dev/bpf. > > Reyk
