-----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?

At that point the only real difference between using the aware driver
versus a non-aware driver is speed, correct?

Again, thanks for helping me get this all figured out.

- -- 

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

Reply via email to