We would like to cover the following topics. This is not an exhaustive list and if you feel there is something missing that you want to talk about, contact the session chair and your topic will be included here.

Please send talks, brainstorm topics, or other proposals to the session leaders, LawrenceStewart and GlebSmirnoff.

• Protocols
  • TCP
    • Deferring reassembly to user thread's kernel context (Lawrence)
    • MPTCP (Lawrence)
    • Deferring mbuf drop on ACK (Scott)
    • UI for controlling TCP/stack dynamics (Lawrence, Andre)
    • Reworking SACK + integrating with reassembly (Andre)
    • Pacing (Lawrence)

• Infrastructure
  • Hostcache (Lawrence)
  • Interface dangling pointers
    • RX pointer in mbufs
      Problem: we don't refcount interface per mbuf which can lead to dangling pointers (particularly problematic in subsystems which hold mbufs for some time e.g. dummynet, netgraph)
    • IOCTLs, rtentries, etc.
  • Stack-driver interface (Andre)
    • RX/TX IFQ/Multiqueue
    • API/advertising hardware offload capabilities (kernel + userland)
  • Making ifnet opaque to driver
    • Juniper proposal?

• Performance optimisation
  • Routing subsystem
    • FIB vs RIB
      Problem: Trie is too generic
    • rtentry locking Problem: Per-packet per-rtentry locking kills performance
      
  • Netgraph (Alexander, Gleb)
    • Topology locking
      Problem: Topology locking hurts performance and doesn't currently protect nodes from all possible config changes which can lead to panic
    • Hand rolled RW locking
      Problem: For nodes that do nothing e.g. ng_tee, atomic inc/dec is too heavy weight, so ideally need a better solution for all nodes
  • Fast path cache misses, amount of memory accessed per read/write (Adrian)

• MBUFS
  • Ref counting (Gleb, Adrian)
    Problem: uint32_t's coming from single zone non contiguous in memory with the mbuf
    
  • Batching
• Multi-(process|thread) accept (Gleb) Problem: Wakeup causes all threads to race and only 1 wins
  
• Light weight ref counter based on count(9) (Gleb)

• Testing/development
  • NSC userspace stack (Lawrence) http://caia.swin.edu.au/urp/incast/tools.html
  • Testing @ Netflix (Lawrence)
  • Testing @ Orange (Olivier)

• Ownership Identify chunks of code without owners

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

To come: Formal documentation of stack driver bounduary (Juniper) Split of ifnet structure into stack owned and driver owned Documentation Adjust all drivers to new world order – request for feedback to mailinglist messages

Version shims or will all vendors be expected to switch? – Shouldn't bee too hard to change – Clear documentation

Will open projects branch for this.

Technical monitor is Ed Maaste from FF

Can change not be one large commit? #ifdef conditionalized, and convert most important drivers sequentially.

One aims is to separate L2 and L3 buy that's outside scope here

Changing the way drivers announce capabilities to stack – idea is to have an area of struct declared by driver like in setsockopt() – list of items that the stack will walk.

It's like newbus. So why not newbus? “Newbus is not just busses, it's also not new (phk)” (Has been reinvented twice, not well since). To be investigated.

There can be additional failure possibilities if functions exported as pointers in list have to allocate memory otherwise will be the same as now.

Vendor capabilities, route to integrate advanced features of hardware.

TCP offload? Is ifnet the right level of abstraction for modern network hardware?

Just in time compilation to improve performance on cache-deep processes? Not a problem now, but it will be tomorrow. There will be cards that offload the entire network stack.

Automagic export of C code at compile time

IFQ interface: pain point different types of workload need different types of parallelism. No one true method like bind one queue to one core. Need flexibility to configure via ifconfig or some other method. ALTQ not working.

Get rid of IFQ and associated softqueue – most HW has hardware support.

The stack will call down completely lockless, (no ifnet lock or driver lock). Drive can implement optimal approach

Pretty much everything uses iftransmit now, except altq. QoS? No explicit API for timing. Intermediary queue discipline? Stack iftransmit function pointer replaced by altq and will call down into driver iftransmit. Multiple layers of queue disipline? nterface only supports one layer.

Work is to prepare proposal, documentation and run performance tests so we can make informed decision

Can we pass in other structures than – eg writing disk blocks directly into network packet? This is another construction site. Whois looking at busdma?

Once documentation etc. looked at, can update drivers.

sometime in the next 4 months.

Common API for common functions for drivers to use, but not stack. Driver can benefit automatically from inprovements

other projects

- move ipsec into pfil filter. Will be able to kldload ipsec. Multiple pfil hooks and can change order - tcpio is about to be completed - crypto code is scattered around source tree.

Vendor feedback: can we move bufferring up into the stack? Control queue lengths and multilayer queue disciplines. Adaptive behaviour dependingon how many packets waiting