This group is locked. No changes can be made to the group while it is locked.
Date 1 - 2 of 2
minutes: IO Visor TSC and Dev Members Call
the tracing micro-conference accepted into Linux Plumbers 2016 !
Hope to see you all in New Mexico.
November is a bit far away, but if you're thinking that you might attend,
please edit the wiki with your talk proposals. 1-5 slides max.
The discussion preferred instead of presentation.
If you're not on attendee list, please add yourself there too,
so we can arrange appropriate room size.
On Thu, May 5, 2016 at 10:02 AM, Brenden Blanco via iovisor-dev
Brenden Blanco <bblanco@...>
Below, please find the meeting minutes from yesterday.
IO Visor had two sessions at OpenStack Summit in Austin last week. The
first was from Yunsong@Huawei , which covered how they are using IO
Visor/BPF in different form factors. The second was from Deepa and
myself, covering how we wrote IO Modules to enforce
application/container policy within CloudFoundry.
On the kernel side, multiple updates:
finishing up direct packet access to improve performance
won't need pseudo skb
simple descriptor: *data, length
tc: read-only access
constant blinding being worked on
push-pop: "change" helper has been in flight for some time, tricky
only really suitable for xdp
mm summit update (see other mail thread)
optimizing page allocator making progress
recycling facility to be used cross devices
page pool allocator would need to be implemented by the driver to add support
dma map/unmap fits in as a constructor/destructor of the page when
returned from the pool to the allocator
lockless qdisc coming soon
possible lockless htb
One Idea Alexei and Brenden were throwing around was to incorporate
CTF - common c-type format, to be used instead of header files for
discovering kernel struct layouts. This could also be used to describe
bpf maps, automatic table pretty-print from kernel.
We also discussed XDP ideas a bit. For now, as Alexei updated in the
page-pool thread, we should try to create a simple forward action that
takes no parameters, and the device has a simple rxq -> txq mapping.
With this action, the packet leaves the same port it came in on. Use
cases could be load-balancer type of device in one-arm mode. More
complicated forwarding behavior could build on top of this without
breaking any ABI.
|1 - 2 of 2|