On Sep 14, 2012, at 7:35 PM, Bob Bregant II <[email protected]> wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Thanks Alfredo! I was pretty sure that I was going to have some of > that all messed up. So, a couple of questions to make sure that I'm > reading your response correctly: > > Standard PF_RING clustering is available for both the stock networking > driver from the manufacturer and for the PF_RING aware driver that you > provide. In either case we should be able to use the rehashing, as > both still pass through the kernel and in both cases I'm still using > PF_RING's libpcap, right? Yes, the main advantage with PF_RING-aware drivers is the transparent_mode=1/2 (the driver copies packets directly into the rings), while the clustering/rehashing is available in both. > At that point the only real difference between using the aware driver > versus a non-aware driver is speed, correct? Yes. > > Again, thanks for helping me get this all figured out. You're welcome. Best Regards Alfredo > > - -- > > Bob Bregant II > Office of Privacy and Information Assurance > University of Illinois at Urbana-Champaign > PGP Key: > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x3EF5417746B6DF9E > > Quis custodiet ipsos custodes? > > On 09/13/12 18:29, Alfredo Cardigliano wrote: >> Hi Bob please see my comments inline >> >> On Sep 14, 2012, at 12:06 AM, Bob Bregant II >> <[email protected]> wrote: >> >> Hi all, >> >> I'm working on using PF_RING to provide load balancing across >> multiple (non-libzero-aware) processes on a single host and >> documenting the various options and their pros/cons to help me >> choose the best setup for a given environment. Speed is always >> good, but proper load balancing is better for my purposes. >> >> So far I've identified several choices that are available and was >> just hoping that someone could provide a little input on whether >> I've got this down properly (all of these assume that you're using >> the PF_RING kernel module and userspace libraries as well as the >> PF_RING libpcap and that you have quick_mode turned off): >> >> 1. Use the stock networking driver. Does load balancing: No. (So >> this doesn't work well for this application, unless you just want >> the speed boost of PF_RING and are using one thread.) >> >>> Actually you can use a cluster in this case. >> >> Faster than: Not using PF_RING. Working BPF: Yes. >> >> 2. Use a PF_RING-aware driver. Does load balancing: Yes, RSS >> queue-based (rehashing possible? Not sure how PF_RING clustering >> fits in here…). >> >>> You can use both in-kernel rehashing (via >>> pfring_enable_rss_rehash() in pf_ring, setting the >>> PF_RING_RSS_REHASH env var in libpcap) or clustering as in (1). >> >> Faster than: Option 1. Working BPF: Yes. >> >> 3. Use a PF_RING DNA driver and DNA. Does load balancing: Yes, >> RSS-queue-based. Faster than: Option 2. Working BPF: No. >> >>> Libpcap includes userspace BPF support. >> >> >> >> 4. Use a PF_RING DNA driver, DNA, and LibZero. Does load balancing: >> Yes, dnacluster-based, 5-tuple by default, custom hashing >> available. Faster than: Option 3. >> >>> Actually this is not faster than (3), both can do line-rate :-) >>> this is definitely more flexible. >> >>> Best Regards Alfredo >> >> Working BPF: No. >> >> Does it seem like all of this is factually accurate? Are there >> any considerations that one might be taking into account when >> deciding between versions that I've omitted? (I've left out cost >> intentionally as I'm looking at it from a purely technical >> perspective.) Are there any options that I've omitted for running >> this application? >> >> Thanks, >> >>> _______________________________________________ Ntop-misc mailing >>> list [email protected] >>> http://listgateway.unipi.it/mailman/listinfo/ntop-misc >> > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.19 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ > > iEYEARECAAYFAlBTau0ACgkQPvVBd0a2356fUwCeMZZtIozj+cN12/k+ApJs7iTh > pzwAoOEDR3TQuVwdP38KyjkVdYv+zhCd > =ImIm > -----END PGP SIGNATURE----- _______________________________________________ Ntop-misc mailing list [email protected] http://listgateway.unipi.it/mailman/listinfo/ntop-misc
