Hi Michal,

I've conducted some testing on v4 of the patch: specifically, wrt how OvS 
reacts in the event of an error condition in the vhost construct/configure 
functions. 

For these tests I hardcoded the listed (DPDK) function to return an error 
value, and observed how the following functions behaved, respectively:
- netdev_dpdk_vhost_construct (server mode only)
- netdev_dpdk_vhost_client_construct (client mode only)
- netdev_dpdk_vhost_client_reconfigure (client mode only)

Results are as follows:

#################################################################################################################################
|  vhost function                               | vhost user mode       | log 
printed?  | undesired behavior?   | details                               |
#################################################################################################################################
| rte_vhost_driver_callback_register    | server                        | yes   
                | no                            | n/a                           
        |
|                                                       | client                
        | yes                   | no                            | n/a           
                        |
+--------------------------------------+---------------------   
+---------------        +-------------------------------------------------      
+
| rte_vhost_driver_disable_features     | server                        | yes   
                | no                            | n/a                           
        |
|                                                       | client                
        | yes                   | no                            | n/a           
                        |
+--------------------------------------+---------------------   
+---------------        +-------------------------------------------------      
+
| rte_vhost_driver_common_construct     | server                        | yes   
                | no                            | n/a                           
        |
|                                                       | client                
        | yes                   | no                            | n/a           
                        |
+--------------------------------------+---------------------   
+---------------        +-------------------------------------------------      
+
| rte_vhost_driver_start                        | server                        
| yes                   | YES                           | vswitchd terminates   
        |
|                                                       | client                
        | yes                   | no                            | n/a           
                        |
+--------------------------------------+---------------------   
+---------------        +-------------------------------------------------      
+
| vhost_common_construct                        | server                        
| yes                   | no                            | n/a                   
                |
|                                                       | client                
        | yes                   | no                            | n/a           
                        |
+--------------------------------------+---------------------   
+---------------        +-------------------------------------------------      
+

In summary, the only issue that I observed is when rte_vhost_driver_start 
returns an error value to netdev_dpdk_vhost_construct, in which case, vswitchd 
terminates - you might want to take a look at this.

Note that performance on the PVP path (with IP forwarding in the guest) was 
marginally higher (~1.5%) with the 17.05 patch.

Finally, I also ran the usual sanity checks, and found no issues:
- checkpatch.py
- patch applies cleanly
- compiles with gcc
- compiles with clang
- sparse
- make check (no additional tests fail)

Thanks,
Mark

>From: ovs-dev-boun...@openvswitch.org [mailto:ovs-dev-boun...@openvswitch.org] 
>On Behalf Of
>William Townsend
>Sent: Wednesday, June 7, 2017 3:57 PM
>To: Aaron Conole <acon...@redhat.com>
>Cc: d...@openvswitch.org
>Subject: Re: [ovs-dev] [PATCH v4] Update relevant artifacts to add support for 
>DPDK 17.05.
>
>Hi Aaron,
>
>On Wed, Jun 7, 2017 at 9:51 AM, Aaron Conole <acon...@redhat.com> wrote:
>
>> Hi Michal,
>>
>> mweglicx <michalx.wegli...@intel.com> writes:
>>
>> > Following changes are applied:>> > - netdev-dpdk: Changes required by DPDK 
>> > API modifications.
>> > - doc: Because of DPDK API changes, backward compatibility
>> >   with previous DPDK releases will be broken, thus all
>> >   relevant documentation entries are updated.
>> > - .travis: DPDK version change from 16.11.1 to 17.05.
>> > - rhel/openvswitch-fedora.spec.in: DPDK version change
>> >   from 16.11 to 17.05.
>> >
>> > v1->v2: Patch rework based on minor review comments.
>> > v2->v3: VHOST user client reconfiguration corrected.
>> > v3->v4: Patch is rebased against OVS master, minor
>> >         rework based on review comments.
>> >
>> > Signed-off-by: Michal Weglicki <michalx.wegli...@intel.com>
>> > ---
>>
>> Since you got some comments from Mark, please describe the motivation
>> for this change with v5.  Something explaining why to move off of the
>> LTS and onto this non-LTS version.  I'm not opposed to moving - just
>> want to know what benefits it brings, and have that recorded as a log
>> in the commit history so that it can be referenced.
>>>> Thanks!
>>
>​A big motivation would be to support new architectures like ARMv8 and
>Power9.
>I have had to move along with DPDK to get this to work.
>​--Bill
>
>_______________________________________________
>> dev mailing list
>> d...@openvswitch.org
>> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>>
>_______________________________________________
>dev mailing list
>d...@openvswitch.org
>https://mail.openvswitch.org/mailman/listinfo/ovs-dev
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to