FreeBSD Developer Summit: Network Receive Performance

Overview

This working group will discuss changes necessary to the interface layers in FreeBSD to deal with current advances in high performance network interfaces including Receive Side Steering, pinning queues to CPUs and other receive side features.

Goals

A list of changes and APIs that will help facility FreeBSD better using the above listed features.

Topics

#

Topic Description

1

APIs for Queue/CPU pinning

2

Queue mapping into higher layers of the stack

Attending

In order to attend you need register for the developer summit as well as by email for the session and be confirmed by the working group organizer. Follow the guidelines described on the main page or what you received by email. For questions or if in doubt ask the session chairs.

Please do NOT add yourself here. Your name will appear automatically once you have received the confirmation email. You need to put your name on the general developer summit attendees list though.

Name

Username / Affiliation

Topics of Interest

Notes

TakuyaAsada

syuu

Michael Bentkofsky

MBentkofsky verisign.com

*

AdrianChadd

adrian

Julien Charbon

jcharbon verisign.com

*

CarlDelsey

carl

MarkJohnston

markj

Sebastian Kuzminsky

S.Kuzminsky at F5.com

*

Mike Karels

mike at karels.net

Jeremiah Lott

jlott at averesystems.com

Mark Johnston

KennethDMerry

ken

DavideItaliano

davide

Juan Mojica

Juan.Mojica at netapp dot com

NeelNatu

neel

GeorgeNevilleNeill

gnn

Session chair

NavdeepParhar

np

Jeffrey Roberson

jeffr

Anuranjan Shukla

anshukla at juniper.net

MikeSilbersack

silby

Ryan Stone

rysto32 at gmail.com

*

Jim Thompson

jim at netgate.com

*

Eric van Gyzen

eric_van_gyzen at dell.com

Bryan Venteicher

bryanv

RobertWatson

rwatson

Nigel Williams

njwilliams at swin.edu.au

Notes

The discussion opened with an attempt to constrain the problem we were trying to solve, including pointing out that any KPI/API suggested needed to be achievable in the next six months.

Some of the existing solutions to the problem of talking to hardware with multiple queues, which all high end NICs currently have, were:

There are several ways to map flows, including: 4 tuple, MAC filter, arbitrary offset. An API that only handles offset, length, value is too simple from the standpoint of getting the right data into the hardware. We need something more rich on the kernel side of the API to that driver writers don't have to figure out our intentions.

Some methods that a good KPI/API ought to have include:

Some consumers of such an API include: Performance, affinity, virtualization, policy, kernel bypass, QoS, and VIMAGE.

We have two patches, for different bits, to start from including Vijay's [RobertWatson] and Randall's [RandallStewart], [GeorgeNevilleNeil]

We need quite a few things, including:

A straw person API includes:

/ComparingMutiqueueSupportLinuxvsFreeBSD

Results

(Add a list or attach slides detailing the achieved results here.)


CategoryHistorical

DevSummit/201305/NetworkReceivePerformance (last edited 2021-04-25T08:17:33+0000 by JethroNederhof)