[ovs-dev] OVS+DPDK rpm

Panu Matilainen pmatilai at redhat.com
Thu Nov 26 09:46:03 UTC 2015


On 11/25/2015 08:27 PM, Aaron Conole wrote:
> Flavio,
>
> Thanks for these questions.
>
> Flavio Leitner <fbl at sysclose.org> writes:
>> Hi,
>>
>> In order to build the Fedora RPM with DPDK some changes to the
>> spec file are required.  However, I was told that not all users
>> want to build with DPDK or even have the DPDK libs installed. It
>> seems a fair request if you are working with OVS only.
>
> I don't know about this being a fair request. From what I can tell, the
> mere existence of DPDK enabled OVS doesn't _require_ that one is using
> DPDK interfaces. I haven't seen a performance impact using DPDK enabled
> OVS. Sounds like irrational fear maybe?

Indeed.

Also at least I haven't personally seen such concerns from anybody 
concretely, I've only heard speculation "some say, some users might not 
want dpdk..." Which is just silly, its just a library which does 
absolutely nothing unless you choose to enable it in OVS config.

What is reasonable is that upstream allows OVS to be built without DPDK. 
Distro packaging is a completely different ball-game where packages are 
typically built with maximum capabilities. It doesn't make the damnest 
difference for the user if "yum install openvswitch" pulls in an 
additional package for libraries.


>> Therefore we have two options.
>> 1) add the option '--with dpdk' to the current spec file, so
>> that users that doesn't want DPDK just follow the usual steps
>> and that's it.  DPDK users only need to pass those two arguments
>> to have the OVS+DPDK RPM files.
>>
>> 2) Create another copy of .spec (openvswitch-dpdk.spec?) with DPDK
>> support enabled.
>
> I don't like this approach; have a complete separate spec just for
> linking with a library seems like not a good approach. Of the two, I
> like the first more, but I'm still thinking "Are there really folks who
> care about -ldpdk"? Hopefully they see this message and let me know what
> I'm not understanding.

--with/--without dpdk is the only sane route for this kind of thing. For 
an upstream spec I think its perfectly reasonable to default to not 
require people wanting to just try it out to package DPDK first, 
especially as long as its configure + build system remains as exotic as 
it is.

>> Another question is static versus shared linking.
>>
>> My opinion is that we should go with (1), shared linked, but I don't
>> know if it covers all use-cases.
>
> I agree - preference is shared linkage. I know this can create a
> possible issue where DPDK ABI goes out of sync - that will need to be
> managed carefully. However, I think it's the _right_ approach because in
> cases where ABI is compatible, it allows really easy upgrading without
> requiring a complete ovs rebuild. In cases where it isn't... well shared
> vs. static is a small fish.

For distro packaging, static linkage generally is not an option at all.

Upstream specs can do what makes most sense for them and is most 
convenient for the target users, the use-case for building an rpm for 
latest upstream version of project X is quite different from managing an 
entire distro. Which in a case like this might well involve a static, 
bundled build of DPDK.

A single spec can support all those, --with/--without dpdk to 
enable/disable it overall, and another option for dynamic linking (to 
packaged system DPDK) vs statically linked, bundled copy.

I can send patch(es) to do this...

	- Panu -

>> Thoughts?
>> Thanks,
>> fbl
>>
>>
>>
>> _______________________________________________
>> dev mailing list
>> dev at openvswitch.org
>> http://openvswitch.org/mailman/listinfo/dev
> _______________________________________________
> dev mailing list
> dev at openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev
>




More information about the dev mailing list