[Differential] D24937: Add sysctl net.iflib.tx_update_freq to set transmit descriptor update frequency

2020-06-23 Thread gallatin (Andrew Gallatin)
gallatin added inline comments. INLINE COMMENTS > iflib.c:590 > +int iflib_tx_update_freq = IFLIB_DEFAULT_TX_UPDATE_FREQ; > +SYSCTL_UINT(_net_iflib, OID_AUTO, tx_update_freq, CTLFLAG_RW, > +&iflib_tx_update_freq, IFLIB_DEFAULT_TX_UPDATE_FREQ, Can you please make this a tunable as

[Differential] D7499: tcp/lro: Make # of LRO entries tunable

2016-08-15 Thread gallatin (Andrew Gallatin)
gallatin accepted this revision. gallatin added a comment. I tend to think type / range checking something like this is overkill.. I'm OK with it as-is.. REVISION DETAIL https://reviews.freebsd.org/D7499 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To

[Differential] D7415: tcp/lro: If timestamps mismatch or it's a FIN, force flush.

2016-08-04 Thread gallatin (Andrew Gallatin)
gallatin accepted this revision. REVISION DETAIL https://reviews.freebsd.org/D7415 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: sepherosa_gmail.com, rrs, np, glebius, hiren, bz, #transport, hselasky, gallatin Cc: freebsd-net-list ___

[Differential] D6689: tcp/lro: Implement hash table for LRO entries.

2016-06-07 Thread gallatin (Andrew Gallatin)
gallatin accepted this revision. gallatin added a comment. Looks good in terms of not killing perf. for the sorted case, and I'm fine with it as-is. However, maybe an else would be better than a goto? REVISION DETAIL https://reviews.freebsd.org/D6689 EMAIL PREFERENCES https://reviews

[Differential] D6406: mbuf: Add a flag for M_HASHTYPE_ to indicate the type has hash properties

2016-05-17 Thread gallatin (Andrew Gallatin)
gallatin added a comment. So the real goal here is to be able to express to the LRO code that you have a hash that is usable as a hash (eg, not just an ordinal queue index), and yet warn the RSS code that it is not a toeplitz rss hash result. Is that correct? REVISION DETAIL https://revi

[Differential] D6137: tcp/lro: Refactor the free/active list operation.

2016-04-29 Thread gallatin (Andrew Gallatin)
gallatin accepted this revision. gallatin added a comment. Thanks, I'm good w/this version REVISION DETAIL https://reviews.freebsd.org/D6137 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: sepherosa_gmail.com, network, adrian, delphij, glebius, hselasky

[Differential] D6137: tcp/lro: Refactor the free/active list operation.

2016-04-28 Thread gallatin (Andrew Gallatin)
gallatin added a comment. The tcp_lro_entry_get() abstraction adds an extra compare to the critical path (the compare against NULL in the function itself, in addition to the same compare in the main routine). At least it does at the C level. Have you verified that the compiler is smart en

[Differential] [Accepted] D5185: tcp/lro: Allow network drivers to set the limit for TCP ACK/data segment aggregation limit

2016-02-05 Thread gallatin (Andrew Gallatin)
gallatin accepted this revision. gallatin added a comment. Thanks for addressing my concerns.. Does anybody else want to comment? REVISION DETAIL https://reviews.freebsd.org/D5185 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: sepherosa_gmail.com, net

[Differential] [Updated] D5185: tcp/lro: Allow network drivers to set the limit for TCP ACK/data segment aggregation limit

2016-02-04 Thread gallatin (Andrew Gallatin)
gallatin added a comment. It might be nice to make these general tunables that could be done centrally and apply to all drivers, but that's probably outside the scope of the review. INLINE COMMENTS sys/netinet/tcp_lro.c:655 Can you just initialize ack_append_limit to the max value for what