From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: What Michael has been working on... Date: Mon, 23 Aug 2021 12:03:01 +0100 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2997251841007807874==" List-Id: --===============2997251841007807874== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello, Because I have been quiet lately I wanted to update everyone a little bit on = what I have been working on in the last couple of weeks. Nothing is a secret, but I have been toying around with a couple of things an= d they are simply not done, yet, so there is nothing to show, but I still wan= ted to keep everyone up to date. Project #1: Benchmarks Together with Daniel, I took an entire day to test performance of our applian= ces. This is something we have done before, but we wanted to know what has ch= anged over the recent software changes, especially with the new kernel. And w= e have discovered some amazing things that the community seems to have genera= lly confirmed on other hardware, too: The new kernel is a lot faster. We spent most time on the IPFire Mini Appliance, because it is (obviously) th= e slowest, but also the most commonly bought model. There is a lot of potenti= al here from which plenty of people would benefit. I do not have my notes with me now while writing this email, but generally, w= e can saturate all interfaces now rather easily using fireperf and we could b= ring up the throughput of the IPS from only a few mbps to about 120 MBit/s (d= uplex). This is a little bit of a mile stone because that makes this applianc= es suitable for a 100 MBit/s connection which it wasn=E2=80=99t really before. We have also experimented a lot with offloading features for network interfac= es so that the OS has less work to do which will result in a couple of change= s soon. There is a lot more we can do to increase throughput even more (see below). We will soon write up all these benchmark results and put them on the wiki, a= lthough we already have lots of patches that will change them again, but we w= ould like to track progress of how much we are improving IPFire. Project #2: IPFire on AWS for ARM IPFire will soon be available on AWS Graviton 2 instances. The code is alread= y done, but the entire product is under review with AWS right now. This going to make IPFire available on a non-Intel/non-AMD-based platform whi= ch is exciting and new and also cheaper. I have a little blog post prepared f= or the release of it and it will strengthen IPFire in the cloud. Project #3: Cake The new kernel is coming with a couple of new features that we can use now an= d so I started playing around with Cake: https://www.bufferbloat.net/projects/codel/wiki/Cake/ I only changed the =E2=80=9Cout-of-the box=E2=80=9D configuration and did not= touch the QoS, yet (lack of time): https://git.ipfire.org/?p=3Dpeople/ms/ipfire-2.x.git;a=3Dcommitdiff;h=3Ddbe= bf0703ee7e36db292534fa03f1d0cc484b370 I have also disabled any extra qdiscs on interfaces where it probably does no= t make too much sense (bridges, GRE/VTI, =E2=80=A6). That should save us a co= uple of CPU cycles again. If anyone wants to deploy this on their systems, I would be happy to hear som= e feedback. Project #4: Making the IPS 100x faster Then, I have been working with Stefan on making the IPS faster. In our benchm= arks, we discovered, that we spent most CPU cycles on copying the data packet= s from the kernel to the user space. That is a very expensive job and has onl= y gotten worse since we have the Spectre/Meltdown fixes everywhere. However, = when the IPS is scanning packets, it cannot always do that very well. For example a TLS connection can be analysed during the handshake, but any tr= affic coming after that is practically random noise. It is encrypted and one = of the goals of TLS is to not give anyone any clue about what might be in the= data packet. So why would we send such a packet to suricata in the first pla= ce? We shouldn=E2=80=99t. And that is what we have been working on which makes the IPS so much faster b= ecause we cut out the bad part that is passing dumb traffic for no reason. We have experimental patches for this, but there is a lot that needs to chang= e for this to work and co-exist with other features that mangle packets, spec= ifically the QoS and NAT. We are working on this and hopefully will be able t= o send a tech preview soon. Yeah, so this is what I have in the pipeline. FYI. Feedback is of course greatly appreciated. Best, -Michael --===============2997251841007807874==--