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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Fri, 15 Jul 2011 02:28:42 +0200
From:	Michał Mirosław <mirq-linux@...e.qmqm.pl>
To:	David Miller <davem@...emloft.net>
Cc:	therbert@...gle.com, bhutchings@...arflare.com,
	netdev@...r.kernel.org
Subject: Re: [PATCH 07/10] net: remove NETIF_F_NO_CSUM feature

On Thu, Jul 14, 2011 at 05:05:06PM -0700, David Miller wrote:
> From: Michał Mirosław <mirq-linux@...e.qmqm.pl>
> Date: Fri, 15 Jul 2011 00:44:45 +0200
> 
> > On Thu, Jul 14, 2011 at 02:31:21PM -0700, David Miller wrote:
> >> From: Michał Mirosław <mirq-linux@...e.qmqm.pl>
> >> Date: Thu, 14 Jul 2011 22:56:23 +0200
> >> > That's why its turned off by default and should be enabled only when user
> >> > knows he will win some pps with it.
> >> More people are going to lose than win by your change.
> >> 
> >> The nocopy feature helps more real situations than it hurts, the
> >> existing default is the best.
> > 
> > I see. I still want to remove NO_CSUM (as I explained in other mail),
> > so would you accept replacing it with something more specific to
> > nocache-copy feature? READS_DATA maybe? That could be later added to
> > sk_route_caps whenever it's known for a route there will be need to
> > read packets' data.
> 
> I don't actually see what the problem is.
> 
> The code wants to conditionalize the nocache-copy feature based upon
> whether hardware will checksum the packet or not.
> 
> And that's exactly what it's testing.
> 
> The reason, of course, is because it doesn't want to enable
> nocache-copy if the cpu is just going to read the data back into it's
> caches during the checksum.  But that's no reason to change the
> flag name to have the word "read" instead of "checksum" in it.

But the real condition is that CPU doesn't read the data. I doesn't matter
if reading is to calculate the checksum or parsing it. The change would
make this obvious.

BTW, 
Best Regards,
Michał Mirosław
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ