LPC 2022 Networking and BPF Track CFP

LPC 2022 Networking and BPF Track CFP

[Daniel Borkmann]

We are pleased to announce the Call for Proposals (CFP) for the Networking and
BPF track at the 2022 edition of the Linux Plumbers Conference (LPC), which is
planned to be held in Dublin, Ireland, on September 12th - 14th, 2022.

Note that the conference is planned to be both in person and remote (hybrid).
CFP submitters should ideally be able to give their presentation in person to
minimize technical issues if circumstances permit, although presenting remotely
will also be possible.

This year's Networking and BPF track technical committee is comprised of:

    David S. Miller <davem@davemloft.net>
    Jakub Kicinski <kuba@kernel.org>
    Paolo Abeni <pabeni@redhat.com>
    Eric Dumazet <edumazet@google.com>
    Alexei Starovoitov <ast@kernel.org>
    Daniel Borkmann <daniel@iogearbox.net>
    Andrii Nakryiko <andrii@kernel.org>

We are seeking proposals of 40 minutes in length (including Q&A discussion).

Any kind of advanced Linux networking and/or BPF related topic will be considered.

Please submit your proposals through the official LPC website at:

    https://lpc.events/event/16/abstracts/

Make sure to select "eBPF & Networking" in the track pull-down menu.

Proposals must be submitted by August 10th, and submitters will be notified of
acceptance by August 12th.

Final slides (as PDF) are due on the first day of the conference.

We are very much looking forward to a great conference and seeing you all!

LPC 2022 Networking and BPF Track CFP (Reminder)

[Daniel Borkmann]

This is a reminder for the Call for Proposals (CFP) for the Networking and
BPF track at the 2022 edition of the Linux Plumbers Conference (LPC), which is
planned to be held in Dublin, Ireland, on September 12th - 14th, 2022.

Note that the conference is planned to be both in person and remote (hybrid).
CFP submitters should ideally be able to give their presentation in person to
minimize technical issues if circumstances permit, although presenting remotely
will also be possible.

This year's Networking and BPF track technical committee is comprised of:

    David S. Miller <davem@davemloft.net>
    Jakub Kicinski <kuba@kernel.org>
    Paolo Abeni <pabeni@redhat.com>
    Eric Dumazet <edumazet@google.com>
    Alexei Starovoitov <ast@kernel.org>
    Daniel Borkmann <daniel@iogearbox.net>
    Andrii Nakryiko <andrii@kernel.org>

We are seeking proposals of 40 minutes in length (including Q&A discussion).

Any kind of advanced Linux networking and/or BPF related topic will be considered.

Please submit your proposals through the official LPC website at:

    https://lpc.events/event/16/abstracts/

Make sure to select "eBPF & Networking" in the track pull-down menu.

Proposals must be submitted by August 10th, and submitters will be notified of
acceptance by August 12th.

Final slides (as PDF) are due on the first day of the conference.

We are very much looking forward to a great conference and seeing you all!

LPC 2022 Networking and BPF Track CFP (Final Reminder)

[Daniel Borkmann]

This is the final reminder for the Call for Proposals (CFP) for the Networking
and BPF track at the 2022 edition of the Linux Plumbers Conference (LPC), which
is planned to be held in Dublin, Ireland, on September 12th - 14th, 2022.

Note that the conference is planned to be both in person and remote (hybrid).
CFP submitters should ideally be able to give their presentation in person to
minimize technical issues if circumstances permit, although presenting remotely
will also be possible.

This year's Networking and BPF track technical committee is comprised of:

    David S. Miller <davem@davemloft.net>
    Jakub Kicinski <kuba@kernel.org>
    Paolo Abeni <pabeni@redhat.com>
    Eric Dumazet <edumazet@google.com>
    Alexei Starovoitov <ast@kernel.org>
    Daniel Borkmann <daniel@iogearbox.net>
    Andrii Nakryiko <andrii@kernel.org>

We are seeking proposals of 40 minutes in length (including Q&A discussion).

Any kind of advanced Linux networking and/or BPF related topic will be considered.

Please submit your proposals through the official LPC website at:

    https://lpc.events/event/16/abstracts/

Make sure to select "eBPF & Networking" in the track pull-down menu.

Proposals must be submitted by August 10th, and submitters will be notified of
acceptance by August 12th.

Final slides (as PDF) are due on the first day of the conference.

We are very much looking forward to a great conference and seeing you all!

Followup from LSF/MM/BPF on standardization/documentation

[Dave Thaler]

At LSF/MM/BPF, the topic was raised about better documenting eBPF and making "standards" like documentation, especially since we are having runtimes other than just Linux now supporting eBPF.  And ideally hosting it under the eBPF Foundation.

I'd like to use this week's BPF office hours slot (Thursday 9am Pacific) to kick off a discussion of this topic, so wanted to send this email to invite anyone interested in contributing to such an effort.   Hopefully we can discuss how to organize the effort and some principles we might use for what might be in scope.

Dave

RE: Followup from LSF/MM/BPF on standardization/documentation

[Dave Thaler]

> -----Original Message-----
> From: Dave Thaler <dthaler@microsoft.com>
> Sent: Monday, August 8, 2022 11:54 AM
> To: bpf@vger.kernel.org
> Subject: Followup from LSF/MM/BPF on standardization/documentation
> 
> At LSF/MM/BPF, the topic was raised about better documenting eBPF and
> making "standards" like documentation, especially since we are having
> runtimes other than just Linux now supporting eBPF.  And ideally hosting it
> under the eBPF Foundation.
> 
> I'd like to use this week's BPF office hours slot (Thursday 9am Pacific) to kick off
> a discussion of this topic, so wanted to send this email to invite anyone
> interested in contributing to such an effort.   Hopefully we can discuss how to
> organize the effort and some principles we might use for what might be in
> scope.
> 
> Dave

FYI, below are today's notes from Daniel Havey...

Dave
-----

Interests:
o	Dave Tucker: maintain rust libs for bpf. 
	-	Lots of questions about basic things. Not covered anywhere centralized.
		>	Want to put into kernel documentation
o	Christoph:In the NVMean computatianal storage
	-	Able to execute programs on a storage device where you have NVME and run them on that device.
		>	eBPF as the binary format for these downloadable programs.
		>	No cannonical spec for eBPF
	-	Is a girhub repo sufficient?
		>	Maybe, a website is preferred - snapshot of pdf
		>	Just need a stable reference
		>	Under eBPF.io
o	Jim: User space NVME drivers
	-	Agree with the above
o	Dave Thaler: Microsoft eBPF architect
	-	Cross-platform - how do we keep track of the different run times
	-	Not diverge - coordinate
Questions:
o	Christoph - verifier, what is in the classic instruction set. Intricate interaction
	-	Yes, verifier expectations exists as a starting point
	-	Linux kernel and Prevail
		>	Uses of uBPF which do not use a verifier
Scope and Organization
o	Cross-plat or Linux or in-between
o	Might be cross-impl vs run-time specific (version specific)
o	Something limited to a single platform or imple
	-	Does this effort care?
o	When does it become standard?
o	Impl or OS specific will get complicated
o	Interest in generic run-time specification
o	NVME perspective - certain eBPF op-codes Linux specific
	-	How does this get impled in the spec?
o	Impl specific opcodes are a slippery slope.
	-	Will get us in trouble.
		>	Avoid going forward.
		>	Let's not make room for vendor specific stuff up front.
o	Is there a use case for impl specific?
o	Decide on the subset of eBPF stuff that is compat amongst runtimes and document stuff that is divergent and call it out.
	-	Hashmaps will likely behave differently anyways
o	To be portable you cannot depend on details of things like what types of hash is used in a hashmap
o	However, functionality should be cross-runtime
o	Abstract concept should be documented
	-	How they are constructed without impl details
	-	Too much impl detail is baaad.
o	Subset of the Linux API and make it a standard?
	-	All of this sounds like a subset of the Linux API?
How do we deal with things that vary?
o	Capability variation
	-	Multiple versioning
	-	Language that is MUST/SHPOUL/MAY
	-	Manditory an optional or conditionaly manditory
o	How to define and split up the run time?
	-	Hashmaps - part of the program type?
	-	Instruction set - bare minimum and extensions
	-	Extensibility by naming extensions and having a bitmap
	-	For runtimes - program types. environments that support everying that is minimum and optional
o	Let's just use MUST/SHOULD/MAY and multiple versions
Components in scope:
o	Initial in-scope too big to be practical
	-	Remove everything except ISA
		>	Prog types in Linux that nobody is using - don't standardize on them
	-	Need instruction set in the ELF format
	-	Verifier expection - exceptions, etc.
	-	What is the job of the verifier vs the runtime
	-	NVME doesn't need as much verification
		>	How much verification is the min?
		>	X86 hardware has a built in verifier.
	-	Kindof verifiers
	-	Some core aspects of verifier make BPF powerfull
		>	For instance: safety
	-	This can be static or dynmic
	-	Probably a MAY
	-	uBPF doesn't have a verifier because probably everything in there is safe?
		>	Or unsafe depending on your viewpoint.
	-	Abstract - mention that there are maps, programs and helpers?
		>	What is eBPF doc. Should this be official doc?
	-	Standardize the parts of ELF format and BTF(?) because the instr set alone is not suffiecient
		>	BTF carries some of the info for the prog to be accepted by the verifier.
	-	Can't document the ELF format without talking about BTF
		>	Could be a SHOULD feature
	-	You can have an ELF file with nothing in it.
	-	FE relocation - should be captured in the spec
		>	BTF can describe variable nature of an NVME command
		>	Instead of raw bytes using BTF to describe might be more flexible
	-	We don't need it initally
	-	On Windows side: No support for BTF except for debugging purposes
	-	Debug info for reporting errors may be useful for NVME
	-	Good to have BTF so people don't start inventing their own thing.
	-	BTF is a low level format that is portable and easily well-described
	-	Load time, meta data
	-	Run time verifications that are not captured should be described by BTF
o	Compilers - are they in scope? Do we describe what the compiler should do?
	-	This probably boils down to details.
	-	What is in-scope, but not covered here
	-	ISA, ELF, BTF and low-level should be very clear what is expected from compiliers
	-	Are we going to write code to verify that you have complied?
		>	Yes, we should do this.
	-	Verifier should be what is checking that the prog is compling
		>	A verifier test suite
	-	Compliance of a BPF program not of a runtime
	-	Stay at the self-test level
		>	If some parts are interchangeable between runtimes great, but don't try too hard for this
	-	Is this a valid BPF opcode, is it handled properly, etc?
		>	Syntactic correctness, can be executed independently of the platform.
	-	Take all the progs offline and dump them into the oracle to see if they are all doing the same things
		>	KP Singh - Yes, I can write this.
		>	uBPF can be the basis of this
	-	Impl JITs - set of values that you load, do some ops and compare the output
	-	Give examples in the doc.
How do we org this effort?
o	PRs and meetings if needed - use office hours
Current doc - most cannocal source of truth is the kernel repo
o	Do we move the source of truth?
o	The source of truth for Linux and the souce of truth for cross-plat are different.
We should move it so that there is only one.
o	Are there legal issues with this idea?
Don't move it, keep it in the kernel tree
o	Keeping in the Linux is a barrier for non-Linux peeps
o	Github is a barrier also.
o	License is a real objection.
o	We must spec license X (MIT?)
o	License is not a strong enough reason to move from kernel to github
o	PDF document somewhere in the eBPF foundation
	-	How does this work?
	-	Do we snap when we have a version and post it?
	-	Host release doc at the foundation.
o	Need another ad-hoc meeting to keep discussing
	-	Something cannonical must appear on the Foundation website
Do we need a mailing list?
o	Can we use the existing BPF list?
	a)	Use the list
	b)	Use the list with magic tag? <-- This one (bpf-doc)
	c)	Use another list.