All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mat Martineau <mathew.j.martineau@linux.intel.com>
To: Geliang Tang <geliang.tang@suse.com>
Cc: Matthieu Baerts <matthieu.baerts@tessares.net>, mptcp@lists.linux.dev
Subject: Re: [PATCH mptcp-next v8 0/8] BPF packet scheduler
Date: Fri, 1 Apr 2022 17:40:38 -0700 (PDT)	[thread overview]
Message-ID: <326dd1ea-98f6-fa43-1f44-e66fadd6d9c8@linux.intel.com> (raw)
In-Reply-To: <20220330141211.GA345@localhost>

On Wed, 30 Mar 2022, Geliang Tang wrote:

> Hi Mat & Matt,
>
> On Tue, Mar 29, 2022 at 04:13:02PM -0700, Mat Martineau wrote:
>>
>> On Tue, 29 Mar 2022, Geliang Tang wrote:
>>
>>> v8:
>>> - use global sched_list instead of pernet sched_list.
>>
>> Yes, I think this is fine. I had initially asked about pernet configuration
>> with respect to registering BPF schedulers, but the important thing is that
>> the sysctl can be set per-namespace.
>>
>>> - drop synchronize_rcu() in mptcp_unregister_scheduler().
>>> - update mptcp_init_sched and mptcp_release_sched as Mat and Florian
>>>   suggested.
>>> - fix the build break in patch 8.
>>> - depends on: "add skc_to_mptcp_sock" v14.
>>> - export/20220325T055307
>>
>> Thanks for updating. Builds and runs fine here.
>>
>> Before we add this to the export branch, have you thought about how subflow
>> data (including the backup bit and throughput/latency data used by the
>> default scheduler) can be accessed in the BPF get_subflow hook? Do you think
>> that can be cleanly added after this series, or is there anything that may
>> need to be changed in this series?
>
> I plan to do that in the next series, BPF round-robin scheduler.
>
> I had implemented round-robin in kernel before:
>
> https://patchwork.kernel.org/project/mptcp/cover/cover.1631011068.git.geliangtang@xiaomi.com/
>
> This time I plan to implement it using BPF.
>
> In order to support bpf_rr, I think we need to do two more things
> based on this series:
>
> 1. Get the subflow data from BPF, maybe iterate over the subflows
> from mptcp_sock.
>

Like we discussed in the meeting, I think a helper function that's 
callable from the BPF code could gather the necessary information from the 
subflows in a safe way.

> 2. Make same members of struct mptcp_sock writable in BPF, say
> last_snd, then we can set it like this:
>
>        msk->last_snd = ssk.

The kernel C code can record which subflow was used last based on the 
previous value returned by the scheduler, or a BPF scheduler could track 
data in a BPF map (I think - I'm not a BPF expert).

For something like last_snd to work, I think we need some way to identify 
subflows that's not the raw ssk pointer. Are there rules about pointer 
usage in BPF that we need to consider?

--
Mat Martineau
Intel

  parent reply	other threads:[~2022-04-02  0:40 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-29  7:09 [PATCH mptcp-next v8 0/8] BPF packet scheduler Geliang Tang
2022-03-29  7:09 ` [PATCH mptcp-next v8 1/8] mptcp: add struct mptcp_sched_ops Geliang Tang
2022-03-29  7:09 ` [PATCH mptcp-next v8 2/8] mptcp: register default scheduler Geliang Tang
2022-03-29  7:09 ` [PATCH mptcp-next v8 3/8] mptcp: add a new sysctl scheduler Geliang Tang
2022-03-29  7:09 ` [PATCH mptcp-next v8 4/8] mptcp: add sched in mptcp_sock Geliang Tang
2022-03-29  7:09 ` [PATCH mptcp-next v8 5/8] mptcp: add get_subflow wrapper Geliang Tang
2022-03-29  7:09 ` [PATCH mptcp-next v8 6/8] mptcp: add bpf_mptcp_sched_ops Geliang Tang
2022-03-29  7:09 ` [PATCH mptcp-next v8 7/8] selftests: bpf: add bpf_first scheduler Geliang Tang
2022-03-29  7:09 ` [PATCH mptcp-next v8 8/8] selftests: bpf: add bpf_first test Geliang Tang
2022-03-30 16:54   ` selftests: bpf: add bpf_first test: Build Failure MPTCP CI
2022-03-30 18:04   ` selftests: bpf: add bpf_first test: Tests Results MPTCP CI
2022-03-29 23:13 ` [PATCH mptcp-next v8 0/8] BPF packet scheduler Mat Martineau
2022-03-30 14:12   ` Geliang Tang
2022-03-30 14:57     ` Matthieu Baerts
2022-04-02  0:40     ` Mat Martineau [this message]
2022-04-02 11:42       ` Matthieu Baerts

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=326dd1ea-98f6-fa43-1f44-e66fadd6d9c8@linux.intel.com \
    --to=mathew.j.martineau@linux.intel.com \
    --cc=geliang.tang@suse.com \
    --cc=matthieu.baerts@tessares.net \
    --cc=mptcp@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.