From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DF0BFC433DF for ; Thu, 27 Aug 2020 15:09:45 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B56EB2177B for ; Thu, 27 Aug 2020 15:09:45 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=tessares-net.20150623.gappssmtp.com header.i=@tessares-net.20150623.gappssmtp.com header.b="iKPgt8S+" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728571AbgH0PJo (ORCPT ); Thu, 27 Aug 2020 11:09:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33734 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728900AbgH0Lyu (ORCPT ); Thu, 27 Aug 2020 07:54:50 -0400 Received: from mail-io1-xd41.google.com (mail-io1-xd41.google.com [IPv6:2607:f8b0:4864:20::d41]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 36B27C061232 for ; Thu, 27 Aug 2020 04:54:40 -0700 (PDT) Received: by mail-io1-xd41.google.com with SMTP id b16so5485047ioj.4 for ; Thu, 27 Aug 2020 04:54:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tessares-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8+USI8ikGwM1YVVvEQswp7iF6TsNadsn4yeIDHk0x60=; b=iKPgt8S+hc3ldLTEfMwzYbyOW2bPHtZf2FLBepIe0Lb/Nl7GROM4sA5jMFIQ8TThaj 7hD0DlbjWo2OBeGZcA/E48756aEptPNWWJA9he9tP15YfRp9mnnqdyqECxAd00QowRMT 0Eu/H+z9WCp8lMWox8PIUwWGqikauK50Txrg7hfNybk74o0hLd5SZCKCWY48CvgdsHBr UMDXtqQqGYefaCTkIv136+mfOKOK+fVqTiSkRCumjBoAS6qVWURyXWF8TPijEe9apjX4 JySNHI+pI2ZfhNPJNqmnQWPPj/ByOWTxtPWyc5+nKs+3dF2H6uhf69PxKNSIsQZWiLH7 3bZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8+USI8ikGwM1YVVvEQswp7iF6TsNadsn4yeIDHk0x60=; b=mTFxywZfvS4TM9jROhk4Od16GpLX1M68AHJGHum6Nhs31fafa8Xhv110Iu3z4sIK3a IDClmv6UNOn8nD7Z8ygH/aNK8Q4O4R5IKJPm9Xknel3WnpJCqMxESLC5CRQ5mRXFMola n2B6a4CXbHvvz3olc3v01U/yRH5YZ7rN/eoAmDDf78MXTY4K2Dvd4zdhwA3++Wo6p9h6 1LUOUSAFjVZpEJX6ZubD5kFGxnFvgpv2QkG3iJQncC+QZrGunN3uJ+KGj5DID0oLIXLW xO9B0Kg+CdW7whNHdFUymgchbAmj/siqkyFTfHfIdodTzF5YAmKJjXExMC+Vb9Ss3JRx BIcg== X-Gm-Message-State: AOAM533+PCRp4ELFV6Ou9/VAisJ4Xk/Pysn3emmKRy+RVcjvHZ/3oisG PRH1wuxy7MSMtSPlLdpCnu7LDS+IEHEFBa1T2KPLdg== X-Google-Smtp-Source: ABdhPJxDt7pGRRQH12hccRAz5CdRFlNU9PBDsLVNqRw8lt88exBLdDxJiJ1WAlEYnsrXg/8+kO677G4mnlkkiBusRXI= X-Received: by 2002:a05:6638:69d:: with SMTP id i29mr5435935jab.138.1598529279389; Thu, 27 Aug 2020 04:54:39 -0700 (PDT) MIME-Version: 1.0 References: <20200821151544.1211989-1-nicolas.rybowski@tessares.net> <20200824220100.y33yza2sbd7sgemh@ast-mbp.dhcp.thefacebook.com> In-Reply-To: From: Nicolas Rybowski Date: Thu, 27 Aug 2020 13:54:28 +0200 Message-ID: Subject: Re: [PATCH bpf-next 0/3] bpf: add MPTCP subflow support To: Alexei Starovoitov Cc: Alexei Starovoitov , Andrii Nakryiko , Daniel Borkmann , "David S. Miller" , Jakub Kicinski , John Fastabend , KP Singh , Martin KaFai Lau , Mat Martineau , Matthieu Baerts , Song Liu , Yonghong Song , bpf , LKML , mptcp@lists.01.org, Network Development Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Alexei, On Wed, Aug 26, 2020 at 9:13 PM Alexei Starovoitov wrote: > > On Tue, Aug 25, 2020 at 11:55 AM Nicolas Rybowski > wrote: > > > > Hi Alexei, > > > > Thanks for the feedback! > > > > On Tue, Aug 25, 2020 at 12:01 AM Alexei Starovoitov > > wrote: > > > > > > On Fri, Aug 21, 2020 at 05:15:38PM +0200, Nicolas Rybowski wrote: > > > > Previously it was not possible to make a distinction between plain TCP > > > > sockets and MPTCP subflow sockets on the BPF_PROG_TYPE_SOCK_OPS hook. > > > > > > > > This patch series now enables a fine control of subflow sockets. In its > > > > current state, it allows to put different sockopt on each subflow from a > > > > same MPTCP connection (socket mark, TCP congestion algorithm, ...) using > > > > BPF programs. > > > > > > > > It should also be the basis of exposing MPTCP-specific fields through BPF. > > > > > > Looks fine, but I'd like to see the full picture a bit better. > > > What's the point of just 'token' ? What can be done with it? > > > > The idea behind exposing only the token at the moment is that it is > > the strict minimum required to identify all subflows linked to a > > single MPTCP connection. Without that, each subflow is seen as a > > "normal" TCP connection and it is not possible to find a link between > > each other. > > In other words, it allows the collection of all the subflows of a > > MPTCP connection in a BPF map and then the application of per subflow > > specific policies. More concrete examples of its usage are available > > at [1]. > > > > We try to avoid exposing new fields without related use-cases, this is > > why it is the only one currently. And this one is very important to > > identify MPTCP connections and subflows. > > > > > What are you thinking to add later? > > > > The next steps would be the exposure of additional subflow context > > data like the backup bit or some path manager fields to allow more > > flexible / accurate BPF decisions. > > We are also looking at implementing Packet Schedulers [2] and Path > > Managers through BPF. > > The ability of collecting all the paths available for a given MPTCP > > connection - identified by its token - at the BPF level should help > > for such decisions but more data will need to be exposed later to take > > smart decisions or to analyse some situations. > > > > I hope it makes the overall idea clearer. > > > > > Also selftest for new feature is mandatory. > > > > I will work on the selftests to add them in a v2. I was not sure a new > > selftest was required when exposing a new field but now it is clear, > > thanks! > > > > > > [1] https://github.com/multipath-tcp/mptcp_net-next/tree/scripts/bpf/examples > > [2] https://datatracker.ietf.org/doc/draft-bonaventure-iccrg-schedulers/ > > Thanks! The links are certainly helpful. > Since long term you're considering implementing path manager in bpf > I suggest to take a look at bpf_struct_ops and bpf based tcp congestion control. > It would fit that use case better. We will definitively take a look at that, thanks ! It is indeed the direction we should take. > For now the approach proposed in this patch is probably good enough > for simple subflow marking. From the example it's not clear what the networking > stack is supposed to do with a different sk_mark. > Also considering using sk local storage instead of sk_mark. It's arbitrary size. Originally, this use-case was asked by Android for some app specific behaviours. But the example is provided here to mainly illustrate the possibility to put different sockopt per subflow knowing their relations with other subflows. Indeed in this example, per se, the marking of the subflows has no interest, it is for illustration purpose only. It was an easy solution to have quick tests in the userspace through nftables. Also, the implementation of all the signals allowing dynamic subflows creation / removal by the path manager to comply with the RFC [1] is still under heavy development on the MPTCP side, so we cannot provide more realistic examples at the moment. [1] https://tools.ietf.org/html/rfc8684#section-3.4