On Mon, Apr 10, 2017 at 09:59:57AM -0700, Joe Stringer wrote:
> Thanks Simon. I also raised with a few people after the discussion about
> how we should document this functionality​. Specifically, whether there
> should be an 'experimental' or 'beta' tag associated. I believe that this
> seemed reasonable to the people I discussed this with.

Thanks Joe,

FWIW that sounds reasonable to me.

> On 8/04/2017 16:48, "Simon Horman" <simon.hor...@netronome.com> wrote:
> 
> At Netdev 2.1 a meeting was held to discuss OvS offload.  Minutes of the
> discussion follow. I apologise in advance for any errors or omissions;
> doubly for any errors in the attendee list.
> 
> Topic: OVS Hardware Offload Using TC
> Date: 7th April 2017
> Location: Netdev 2.1, Montreal
> Attendees: Aaron Conole, Ben LaHaise, Eran Ben Elisha, Hannes Frederic Sowa,
>   Jakub Kicinski, Jiri Pirko, Joe Stringer, John Fastabend, Nick Viljoen,
>   Rashid Khan, Rony Efraim, Simon Horman
> 
> Joe raised 2 concerns:
> 
> 1) How to enable users to understand whether offload is
>    successful and if not, why not?
> 
>   a) There is functionality in the v7[1] patchset to report which flows
>      are present in hardware.
> 
>   b) New error reporting infrastructure from the kernel is forthcoming It
>      should allow TC to provide more error information if a flow can't be
>      added to hardware. This could be made available to users - e.g. logged
>      - to allow them better understand the reason for the failure.
> 
> 2) Maintenance burden falling on existing maintainers
> 
>   a) Simon offered to take some of the maintenance burden
>      immediately as he is already a committer.
> 
>   b) The aim is to ensure that in future there are other committers
>      who are interested in this feature.
> 
>   There was consensus that if the feature-set does not grow there should be
>   discussion of deprecating the HW offload support provided by [1].
> 
> Joe raised issue of whether OVS should probe hardware capabilities at
> runtime.
> John suggested this may be complex; potential combinatorial set is too
> large.
> 
> Rony then raised the increased complexity of using multiple NICs of
> different types with different offload capabilities, this was tabled to a
> later date.
> 
> Joe has expressed a desire for more testing. There was a general agreement
> to contribute tests.
> 
> [1] [PATCH ovs V7 00/24] Introducing HW offload support for openvswitch
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to