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]
Message-ID: <CALx6S36n68LjzyfYbBNR+aLEJxK9cp1HefhP22mNCPNrcSGJQQ@mail.gmail.com>
Date:	Tue, 29 Sep 2015 10:17:17 -0700
From:	Tom Herbert <tom@...bertland.com>
To:	Florian Westphal <fw@...len.de>
Cc:	David Miller <davem@...emloft.net>,
	Linux Kernel Network Developers <netdev@...r.kernel.org>,
	Kernel Team <kernel-team@...com>
Subject: Re: [PATCH net-next 0/4] ila: Use NF_INET_PRE_ROUTING nfhook

On Mon, Sep 28, 2015 at 4:00 PM, Florian Westphal <fw@...len.de> wrote:
> Tom Herbert <tom@...bertland.com> wrote:
>> RFC6296 doesn't work because it allows an invalid checksum to be sent
>> on wire relative to the addresses used on the wire. That means we
>> would lose CHECKSUM_UNNECESSARY for ILA which is way too big of a
>> performance hit.
>
> Not following.  I did not say you should use NPT instead of ILA.
>
> [..]
>> In any case, I did at one point create some netfilter targets for ILA
>> to do the translation correctly updating the checksum. While this
>> provided the required functionality, I couldn't get sufficient
>> performance. A specialized fixed length lookup table gets most of the
>> performance needed for ILA.
>
> I'm not following at all.
>
> Could you explain why you can't just 'relocate' your proposed
> implementation to netfilter/ipv6?
>
Florian

I modified DNPT to perform ILA. Performance results are below. What I
see is that DNPT offers only a slight improvement over just doing
translation at LWT and not getting a hit in early demux. Top function
in perf is:

2.49%  [kernel]                   [k] ip6t_do_table

so I think this performance result is mostly the overhead of netfilter
and not ILA translation. But in any case, doing a direct specialized
lookup like what we do in this patch gets us close to same performance
without ILA enabled-- low performance overhead is critical for our ILA
use cases.

Tom

No ILA, baseline
   85.72% CPU utilization
   1861945 tps
   93/163/330 50/90/99% latencies

ILA before fix (LWT on both input and output)
   83.47 CPU utilization
   16583186 tps (-11% from baseline)
   107/183/338 50/90/99% latencies

ILA after fix (hook for input)
   84.97% CPU utilization
   1833948 tps (-1.5% from baseline)
   95/164/331 50/90/99% latencies

Modify DNPT to do ILA (ip6tables -t mangle -I PREROUTING -d
2001:0:0:3::/64 -j DNPT --src-pfx 2001:0:0:3::/64 --dst-pfx
3333:0:0:1::/64)
   80.94% CPU utilization
   1683315 tps (-10% from baseline)
   104/179/350 50/90/99% latencies

> F.e. I see no reason why you could not use a lookup table in a netfilter
> target (or nft expression, for that matter) ... ?
>
> Thanks,
> Florian
--
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