> > > Should this have some additional cover for the ENOSPC case? Meaning,
> > we
> > > will now increment a failure condition, but I'm not sure it should be
> > > considered an 'upcall' failure? After all, we'll still perform the
> > actions.
> >
> > Good question. I inherited
> Sent: Monday, 18 December, 2017 19:41
> > To: Jan Scheurich
> > Cc: d...@openvswitch.org
> > Subject: Re: [ovs-dev] [PATCH v4 1/3] dpif-netdev: Refactor PMD
> performance into dpif-netdev-perf
> >
> > Hi Jan,
> >
>
Scheurich
> Cc: d...@openvswitch.org
> Subject: Re: [ovs-dev] [PATCH v4 1/3] dpif-netdev: Refactor PMD
performance into dpif-netdev-perf
>
> Hi Jan,
>
> Jan Scheurich writes:
>
> > Add module dpif-netdev-perf to host all PMD performance
Hi Aaron,
Thanks for the review. Answers in-line.
Regards, Jan
> -Original Message-
> From: Aaron Conole [mailto:acon...@redhat.com]
> Sent: Monday, 18 December, 2017 19:41
> To: Jan Scheurich
> Cc: d...@openvswitch.org
> Subject: Re: [ovs-dev] [PATCH v4 1/3] dpif-ne
Hi Jan,
Jan Scheurich writes:
> Add module dpif-netdev-perf to host all PMD performance-related
> data structures and functions in dpif-netdev. Refactor the PMD
> stats handling in dpif-netdev and delegate whatever possible into
> the new module, using clean interfaces to shield dpif-netdev from
Add module dpif-netdev-perf to host all PMD performance-related
data structures and functions in dpif-netdev. Refactor the PMD
stats handling in dpif-netdev and delegate whatever possible into
the new module, using clean interfaces to shield dpif-netdev from
the implementation details. Accordingly,
