On 11/25/2015 08:27 PM, Aaron Conole wrote:
Flavio,
Thanks for these questions.
Flavio Leitner <f...@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@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
