lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <CACKFLikoKktanhxgaMeSA0NGmA6RiaBnxnCXUYfcssYWefdMVg@mail.gmail.com> Date: Wed, 3 Aug 2016 15:15:35 -0700 From: Michael Chan <michael.chan@...adcom.com> To: Rick Jones <rick.jones2@....com> Cc: skallam <siva.kallam@...adcom.com>, David Miller <davem@...emloft.net>, Netdev <netdev@...r.kernel.org>, Prashant Sreedharan <prashant@...adcom.com>, Satish Baddipadige <satish.baddipadige@...adcom.com> Subject: Re: [PATCH net 1/2] tg3: Fix for diasllow rx coalescing time to be 0 On Wed, Aug 3, 2016 at 9:04 AM, Rick Jones <rick.jones2@....com> wrote: > > Should anything then happen with: > > /* No rx interrupts will be generated if both are zero */ > if ((ec->rx_coalesce_usecs == 0) && > (ec->rx_max_coalesced_frames == 0)) > return -EINVAL; > > > which is the next block of code? The logic there seems to suggest that it > was intended to be able to have an rx_coalesce_usecs of 0 and rely on packet > arrival to trigger an interrupt. Presumably setting rx_max_coalesced_frames > to 1 to disable interrupt coalescing. > I remember writing this block of code over 10 years ago for early generations of the chip. Newer chips seem to behave differently and rx_coalesce_usecs can never be zero. So this block can be removed now that the condition can never be true. We should probably leave a comment there for future reference.
Powered by blists - more mailing lists