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.
A list of changes and APIs that will help facility FreeBSD better using the above listed features.
| # | Topic Description |
|---|---|
| 1 | APIs for Queue/CPU pinning |
| 2 | Queue mapping into higher layers of the stack |
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 |
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:
(Add a list or attach slides detailing the achieved results here.)