From: Michał Mirosław <mirq-linux@rere.qmqm.pl> Date: 2011-07-14 20:56:25
On Wed, Jul 13, 2011 at 05:30:37PM -0700, Tom Herbert wrote:
On Wed, Jul 13, 2011 at 5:23 PM, Ben Hutchings [off-list ref]wrote:
quoted
On Thu, 2011-07-14 at 02:10 +0200, Michał Mirosław wrote:
quoted
There are no explicit users, so this is now equivalent to
NETIF_F_HW_CSUM.
[...]
I think this is still a useful distinction, even the networking core
currently doesn't care about the difference.
Agreed. It seems like this is the only way to distinguish virtual devices
from HW devices (like we did with nocachecopy check).
You can't reliably detect virtual devices by this method. No tunnel devices
use this flag and it also doesn't detect e.g. IPsec being used on the route
(and no-cache copy should be disabled at least for software encryption).
That's why its turned off by default and should be enabled only when user
knows he will win some pps with it.
Best Regards,
Michał Mirosław
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.
Best Regards,
Michał Mirosław
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.
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