; To: Adrian Chadd
> Cc: Andre Oppermann; Alan Somers; n...@freebsd.org; Jack F Vogel; Justin T.
> Gibbs; Luigi Rizzo; T.C. Gubatayao
> Subject: Re: Flow ID, LACP, and igb
>
> Are you using a pcie3 bus? Of course this is only an issue for 10g; what
pct of
> FreeBSD users have a lo
On Mon, Sep 2, 2013 at 2:47 PM, Barney Cordoba wrote:
>
> In a week I ripped out the offload crap and the 9000 sysctls, eliminated the
> "consumer buffer" problem, reduced locking by 40% and now the igb driver
> uses 20% less cpu with a full gig load.
>
Wow!
where is the patch ? I would like to
s cleaner and more easily maintained.
BC
From: Adrian Chadd
To: Barney Cordoba
Cc: Andre Oppermann ; Alan Somers ;
"n...@freebsd.org" ; Jack F Vogel ; Justin
T. Gibbs ; Luigi Rizzo ; T.C. Gubatayao
Sent: Sunday, September 1, 2013 4:51 PM
Subject: Re: Fl
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02.09.2013 00:45, Adrian Chadd wrote:
>
>
> Not sure about igb, but ixgbe (according to advanced RX descriptor
> format, 7.1.6.2 @ 82599 datasheet) can provide 'real' RSS value
> which can be used in m_flowid instead of NIC queue id.
>
> (And, b
> From: Luigi Rizzo
> To: Barney Cordoba
> Cc: Andre Oppermann ; Alan Somers ;
> "n...@freebsd.org" ; Jack F Vogel ;
> Justin T. Gibbs ; T.C. Gubatayao <
> tgubata...@barracuda.com>
> Sent: Saturday, August 31, 2013 10:27 PM
> Subject: R
> Not sure about igb, but ixgbe (according to advanced RX descriptor
> format, 7.1.6.2 @ 82599 datasheet) can provide 'real' RSS value which
> can be used in m_flowid instead of NIC queue id.
>
> (And, by the way, another RSS-related problem:
> there are cases when setting flowid does more harm, fo
Oppermann ; Alan Somers ;
"n...@freebsd.org" ; Jack F Vogel ; Justin
T. Gibbs ; T.C. Gubatayao
Sent: Saturday, August 31, 2013 10:27 PM
Subject: Re: Flow ID, LACP, and igb
On Sun, Sep 1, 2013 at 4:15 AM, Barney Cordoba wrote:
> ...
>
[your point on testing with realistic assu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 26.08.2013 21:18, Justin T. Gibbs wrote:
> Hi Net,
>
> I'm an infrequent traveler through the networking code and would
> appreciate some feedback on some proposed solutions to issues
> Spectra has seen with outbound LACP traffic.
>
> lacp_select
On Sun, Sep 1, 2013 at 4:15 AM, Barney Cordoba wrote:
> ...
>
[your point on testing with realistic assumptions is surely a valid one]
>
> Of course there's nothing really wrong with OOO packets. We had this
> discussion before; lots of people
> have round robin dual homing without any ill effe
Gibbs ; Andre
Oppermann ; "n...@freebsd.org"
Sent: Saturday, August 31, 2013 9:38 PM
Subject: RE: Flow ID, LACP, and igb
On Sat, Aug 31, 2013 at 8:41 AM, Barney Cordoba
wrote:
> Also, the *most* important thing is distribution with realistic data. The goal
> should be to use
On Sat, Aug 31, 2013 at 8:41 AM, Barney Cordoba
wrote:
> Also, the *most* important thing is distribution with realistic data. The goal
> should be to use the most trivial function that gives the most balanced
> distribution with real numbers. Faster is not better if the result is an
> unbalance
twice as fast as
hash % SLOTS;
BC
From: Luigi Rizzo
To: Alan Somers
Cc: Jack F Vogel ; "n...@freebsd.org" ;
Justin T. Gibbs ; Andre Oppermann ; T.C.
Gubatayao
Sent: Friday, August 30, 2013 8:04 PM
Subject: Re: Flow ID, LACP, and igb
Alan,
On
mann ; T.C.
Gubatayao
Sent: Friday, August 30, 2013 8:04 PM
Subject: Re: Flow ID, LACP, and igb
Alan,
On Thu, Aug 29, 2013 at 6:45 PM, Alan Somers wrote:
>
>
> ...
> I pulled all four hash functions out into userland and microbenchmarked
> them. The upshot is that hash32
Alan,
On Thu, Aug 29, 2013 at 6:45 PM, Alan Somers wrote:
>
>
> ...
> I pulled all four hash functions out into userland and microbenchmarked
> them. The upshot is that hash32 and fnv_hash are the fastest, jenkins_hash
> is slower, and siphash24 is the slowest. Also, Clang resulted in much
> f
On Thu, Aug 29, 2013 at 3:40 PM, T.C. Gubatayao
wrote:
> On Aug 29, 2013, at 4:21 PM, Alan Somers wrote:
>
>> They're faster, but even with this change, jenkins_hash is still 6 times
>> slower than FNV hash.
>
> Actually, I think your test isn't accurately simulating memory access, which
> might
On Aug 29, 2013, at 5:40 PM, T.C. Gubatayao wrote:
> On Aug 29, 2013, at 4:21 PM, Alan Somers wrote:
>
>> They're faster, but even with this change, jenkins_hash is still 6 times
>> slower than FNV hash.
>
> Actually, I think your test isn't accurately simulating memory access, which
> might be s
On Aug 29, 2013, at 4:21 PM, Alan Somers wrote:
> They're faster, but even with this change, jenkins_hash is still 6 times
> slower than FNV hash.
Actually, I think your test isn't accurately simulating memory access, which
might be skewing the results.
For example, from net/if_lagg.c:
On Thu, Aug 29, 2013 at 1:33 PM, T.C. Gubatayao wrote:
> On Aug 29, 2013, at 12:45 PM, Alan Somers wrote:
>
> > I pulled all four hash functions out into userland and microbenchmarked
> them.
> > The upshot is that hash32 and fnv_hash are the fastest, jenkins_hash is
> > slower, and siphash24 is
On Aug 29, 2013, at 12:45 PM, Alan Somers wrote:
> I pulled all four hash functions out into userland and microbenchmarked them.
> The upshot is that hash32 and fnv_hash are the fastest, jenkins_hash is
> slower, and siphash24 is the slowest. Also, Clang resulted in much faster
> code than gcc.
On Thu, Aug 29, 2013 at 1:42 AM, Alan Somers wrote:
> On Mon, Aug 26, 2013 at 2:40 PM, Andre Oppermann
> wrote:
>
> > On 26.08.2013 19:18, Justin T. Gibbs wrote:
> >
> ...
>
> >> Are there other checksums we should be looking at in addition to FNV?
> >>
> >
> > siphash24() is fast, keyed and str
On Thu, Aug 29, 2013 at 1:27 AM, T.C. Gubatayao wrote:
> > No problem with fnv_hash().
>
> Doesn't it have bad mixing? Good distribution is important since this
> code is
> for load balancing.
>
The poor mixing in FNV hash comes from the 8-bit XOR operation. But that
provides fine mixing of the
> No problem with fnv_hash().
Doesn't it have bad mixing? Good distribution is important since this code is
for load balancing.
FNV is also slower compared to most of the newer non-cryptographic hashes,
certainly on large keys, but even on small ones. Of course, performance will
vary with the a
On 29.08.2013 01:42, Alan Somers wrote:
On Mon, Aug 26, 2013 at 2:40 PM, Andre Oppermann wrote:
On 26.08.2013 19:18, Justin T. Gibbs wrote:
Hi Net,
I'm an infrequent traveler through the networking code and would
appreciate some feedback on some proposed solutions to issues Spectra
has seen
On Mon, Aug 26, 2013 at 2:40 PM, Andre Oppermann wrote:
> On 26.08.2013 19:18, Justin T. Gibbs wrote:
>
>> Hi Net,
>>
>> I'm an infrequent traveler through the networking code and would
>> appreciate some feedback on some proposed solutions to issues Spectra
>> has seen with outbound LACP traffic
On 27.08.2013 01:30, Adrian Chadd wrote:
... is there any reason we wouldn't want to have the TX and RX for a given flow
mapped to the same core?
They are. Thing is the inbound and outbound packet flow id's are totally
independent from each other. The inbound one determines the RX ring it
wi
On Aug 26, 2013, at 5:30 PM, Adrian Chadd wrote:
> ... is there any reason we wouldn't want to have the TX and RX for a given
> flow mapped to the same core?
>
Given than an inbound ACK is likely to be turned into an outbound segment
from within the same execution context and CPU instance, I c
None that I can think of.
On Mon, Aug 26, 2013 at 4:30 PM, Adrian Chadd wrote:
> ... is there any reason we wouldn't want to have the TX and RX for a given
> flow mapped to the same core?
>
>
>
>
> -adrian
>
___
freebsd-net@freebsd.org mailing list
ht
... is there any reason we wouldn't want to have the TX and RX for a given
flow mapped to the same core?
-adrian
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-n
On 26.08.2013 19:18, Justin T. Gibbs wrote:
Hi Net,
I'm an infrequent traveler through the networking code and would
appreciate some feedback on some proposed solutions to issues Spectra
has seen with outbound LACP traffic.
lacp_select_tx_port() uses the flow ID if it is available in the outbou
On Mon, Aug 26, 2013 at 11:18 AM, Justin T. Gibbs wrote:
> Hi Net,
>
> I'm an infrequent traveler through the networking code and would
> appreciate some feedback on some proposed solutions to issues Spectra
> has seen with outbound LACP traffic.
>
> lacp_select_tx_port() uses the flow ID if it i
Hi Net,
I'm an infrequent traveler through the networking code and would
appreciate some feedback on some proposed solutions to issues Spectra
has seen with outbound LACP traffic.
lacp_select_tx_port() uses the flow ID if it is available in the outbound
mbuf to select the outbound port. The igb
31 matches
Mail list logo
