From mboxrd@z Thu Jan 1 00:00:00 1970 From: Martijn van Oosterhout Subject: Re: AF_PACKET fanout not working on MPLS traffic Date: Tue, 15 Jan 2019 09:22:50 +0100 Message-ID: <20190115082250.GA23010@svana.org> References: <20190114184046.GA22481@svana.org> Reply-To: Martijn van Oosterhout Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="DocE+STaALJfprDB" Cc: Network Development To: Willem de Bruijn Return-path: Received: from svana.org ([113.212.99.187]:57520 "EHLO svana.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727703AbfAOIW4 (ORCPT ); Tue, 15 Jan 2019 03:22:56 -0500 Content-Disposition: inline In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: --DocE+STaALJfprDB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hoi Willem, On Mon, Jan 14, 2019 at 03:03:42PM -0500, Willem de Bruijn wrote: > On Mon, Jan 14, 2019 at 2:12 PM Martijn van Oosterhout wrote: > > I see a two ways this could be fixed. > > > > Option 1: include FLOW_DISSECTOR_KEY_MPLS in > > flow_keys_dissector_symmetric but that seems a big assumption, we don't > > do that for VLANs for example. >=20 > This sounds fine to me. Though it will require extra work to make > __skb_get_has_symmetric actually use the entropy. And in practice it's > not clear that this will result in much entropy. Ok, I guess this really depends on the kind of traffic. You'd have to assume that flows in both directions get the same labels, which may or may not be true. (The assumption here is that you want flows to stay together, otherwise you may as well use round-robin). > > And there is actually another problem: MPLS provides no information > > about the next header because it assumes the endpoints in the network > > recognise the MPLS headers. Which means you'd have to make a guess > > about what the next layer should be. >=20 > This is the real issue. I don't think this can be done in general > purpose code. The new BPF flow dissector, however, does allow you to > deploy a custom dissector in environments where the inner protocol is > known. >=20 > https://lwn.net/Articles/764200/ Thanks for the reference! Is this code considered mature enough for production? Also, since this is new, I can't find much info on how to use it. But if I understand correctly you create a flow dissector in BPF which extracts the various parts. There is one such dissector per namespace, it replaces the internal one completely. You attach it using bpftool[1], which loads the program and confiigures where the BPF program will store various keys. We can then make a BPF program which works for our traffic, load it and then the hashing code from AF_PACKET will start using it instead of the builtin dissector. Does that sound right? [1]: https://patchwork.kernel.org/patch/10673201/ Thanks in advance, --=20 Martijn van Oosterhout http://svana.org/kleptog/ > The combine: one man, one day, wheat for half a million loaves of bread. --DocE+STaALJfprDB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBXD2YWUvt++dL5i1EAQiIVg//Qos3xDPhrx4R24qbEmwJiISE1KdRhpBl ozGaeX5tij6G2tcjvf8F+Q66nGA+omxD7HgqyuJu0QMbhwEL9Bv7LZaQcZW/EbIL fFJ5NHJ3aeJQ76BoxjWm7ZtziGkSVKPYthPo5s8Qs9an3yVmhcM0NGqspuLpH5wI SmagCcxb1y75uNrEVKVSL+Df0FTj91r2Z2UeBD9SbDou8J5p7dupK3Oqt99s9a+H a/Zv3fOjf1USqYwV3ATcpmSmDRj4KDgcuZKEO/fAjdi5etn3Kv8CMHoEdiAIzqvj DJigo/8BYivf0DG2ZP8RBYJQZHP5q66qbU0VMG9fMfcGnqvMKgnqH7Gi+9N0jhTh 0kznvo1LpsoixYeOpHNQXlUeBMNNNpef56NhxhjD4FRDwRS9M1+/FTffvL5+SxZu bYSiP0MMSikacH8WilVUsQftoYKvF3vOS45B1T+ZpSTchoLvfof2E94fDXICM7PM krsb5f/I21jb035wxZJ0LnUvQNZZVQOlNZ+ULxA6/FmlmzMGMr6a5l5xJCpPW6EK GEgx5V2XbaviQh9RPFB3/zh/R/zfsx0cWLKNGmY1OYiR4WjD2vc/awk9wIfLikl3 WL4WpZO9gkxa+fNWM6RZDdJl85NzvP2KlcaoRst4XsNqVNZq1ynzFw6Ba6l5RHs3 iFpHFkpyC2c= =VHaU -----END PGP SIGNATURE----- --DocE+STaALJfprDB--