>From: Christian Ehrhardt [mailto:christian.ehrha...@canonical.com] >Sent: Monday, November 20, 2017 1:04 PM >To: Kavanagh, Mark B <mark.b.kavan...@intel.com> >Cc: <d...@openvswitch.org> <d...@openvswitch.org>; maxime.coque...@redhat.com >Subject: Re: [ovs-dev] [RFC PATCH V2 1/2] netdev-dpdk: DPDK v17.11 upgrade > >On Wed, Nov 8, 2017 at 1:00 PM, Mark Kavanagh <mark.b.kavan...@intel.com> >wrote: >> This commit adds support for DPDK v17.11: >> - minor updates to accomodate DPDK API changes >> - update references to DPDK version in Documentation >> - update DPDK version in travis' linux-build script >> >> Signed-off-by: Mark Kavanagh <mark.b.kavan...@intel.com> > > >> diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c >> index 76e79be..ed5bf62 100644 >> --- a/lib/netdev-dpdk.c >> +++ b/lib/netdev-dpdk.c >> @@ -26,6 +26,7 @@ >> #include <sys/socket.h> >> #include <linux/if.h> >> >> +#include <rte_bus_pci.h> >> #include <rte_config.h> >> #include <rte_cycles.h> >> #include <rte_errno.h> >> @@ -150,8 +151,8 @@ BUILD_ASSERT_DECL((MAX_NB_MBUF / >ROUND_DOWN_POW2(MAX_NB_MBUF/MIN_NB_MBUF)) >> >> #define DPDK_ETH_PORT_ID_INVALID RTE_MAX_ETHPORTS >> >> -/* DPDK library uses uint8_t for port_id. */ >> -typedef uint8_t dpdk_port_t; >> +/* DPDK library uses uint16_t for port_id. */ >> +typedef uint16_t dpdk_port_t; >> >> #define VHOST_ENQ_RETRY_NUM 8 >> #define IF_NAME_SZ (PATH_MAX > IFNAMSIZ ? PATH_MAX : IFNAMSIZ) >> @@ -2582,7 +2583,7 @@ netdev_dpdk_detach(struct unixctl_conn *conn, int argc >OVS_UNUSED, >> { >> int ret; >> char *response; >> - uint8_t port_id; >> + dpdk_port_t port_id; >> char devname[RTE_ETH_NAME_MAX_LEN]; >> struct netdev_dpdk *dev; > >Hi Mark, >I today independently came to exactly the same changes to get it >building until I saw this mail. >We discussed the option to handle things depending on the DPDK version >built against via config time checks, but then as OVS "defines" a DPDK >version that it matches you might not want/need that complexity.
Hi Christian, Thanks for the review/ack. Can you provide some additional details regarding the config time checks that you mentioned? Thanks in advance, Mark >That said it implies I reviewed and tested (well built) them, so >bumping the thread and feel free to add: >Reviewed-by: Christian Ehrhardt <christian.ehrha...@canonical.com> _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
