Differences

This shows you the differences between two versions of the page.

--- 0x13:reports:d1t1t04-hardware-offload-workshop [2019/04/03 21:22] – ehalep
+++ 0x13:reports:d1t1t04-hardware-offload-workshop [2019/09/28 17:04] (current) – external edit 127.0.0.1
@@ Line 7: / Line 7: @@
 The discussion started with the general switch ASIC offload and the many devlink updates, such as health Monitor, which monitors device health, and is used to pass information from the device to upper layer.
-There was a discussion about the need to have more hardware counter visibility for upper layers in the stack, right now the hardware has lots of stat counters, programmable ones but they are not tied well into the different layers in the stack.
+There was a discussion about the need to have more hardware counter visibility for upper layers in the stack. Right now the hardware has lots of stat counters, programmable ones but they are not tied well into the different layers in the stack.
 The discussion then shifted to packet drop visibility in the Control plane which is very important. The proposed solutions are:
@@ Line 28: / Line 28: @@
 The next talk was about Doorbell overflow recovery. The topic of discussion was the discovery and recovery for RDMA queues. Possible solutions were fast dequeuing, CPU stall and drop message detection and recovery procedures.
-This talk was followed by Qos Ingress Rate limiting and OVS offload with TC. One focus was on Ingress rate limiting and policing. The rate limited was done with TC offload by adding a matchall type cls with police action and Introducing reserved Priorities. OVS should install Tc filters with priority offset, reserve higher priority for rate limiting.
+This talk was followed with Qos Ingress Rate limiting and OVS offload with TC. The focus was on ingress rate limiting and policing. The rate limited was done with TC offload by adding a matchall type cls with police action and introducing reserved priorities. OVS should install Tc filters with priority offset, reserve higher priority for rate limiting.
-Possible issues with ovs-tc offload were when going from software to hardware, tc police is in software and filters are offloaded, this could break semanting. Possible solutions include reverting to original semantics of policing with offload isn't supported and ovs forcing tc filters in software only.
+A possible issue with ovs-tc offload is when going from software to hardware, tc police is in software and filters are offloaded, this could break semanting. Possible solutions include reverting to original semantics of policing with offload isn't supported and ovs forcing tc filters in software only.
 Rony raised the question of why were priorities chosen vs chains. The answer was that recirculation is a good use case for chains.
@@ Line 55: / Line 55: @@
 The talk was concluded with reasons it's been implemented that way, as the devlink tool and bus model fits requirements such as providing vendor agnostic solution and multi-port subdevice creation.
-Site: https://www.netdevconf.org/0x13/session.html?workshop-hardware-offload
+Site: https://www.netdevconf.info/0x13/session.html?workshop-hardware-offload
-Slides:
-Videos: