* [PATCH v2 31/31] net/i40e: remove unused macro from PMD
From: Jingjing Wu @ 2016-12-09 14:39 UTC (permalink / raw)
To: dev; +Cc: jingjing.wu, helin.zhang
In-Reply-To: <1481294364-83505-1-git-send-email-jingjing.wu@intel.com>
Signed-off-by: Jingjing Wu <jingjing.wu@intel.com>
---
drivers/net/i40e/Makefile | 2 +-
drivers/net/i40e/i40e_ethdev.c | 40 ----------------------------------------
2 files changed, 1 insertion(+), 41 deletions(-)
diff --git a/drivers/net/i40e/Makefile b/drivers/net/i40e/Makefile
index 13085fb..66997b6 100644
--- a/drivers/net/i40e/Makefile
+++ b/drivers/net/i40e/Makefile
@@ -38,7 +38,7 @@ LIB = librte_pmd_i40e.a
CFLAGS += -O3
CFLAGS += $(WERROR_FLAGS) -DPF_DRIVER -DVF_DRIVER -DINTEGRATED_VF
-CFLAGS += -DX722_SUPPORT -DX722_A0_SUPPORT
+CFLAGS += -DX722_A0_SUPPORT
EXPORT_MAP := rte_pmd_i40e_version.map
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index b2f827c..f42f4ba 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -6198,18 +6198,14 @@ i40e_parse_hena(uint64_t flags)
rss_hf |= ETH_RSS_FRAG_IPV4;
if (flags & (1ULL << I40E_FILTER_PCTYPE_NONF_IPV4_TCP))
rss_hf |= ETH_RSS_NONFRAG_IPV4_TCP;
-#ifdef X722_SUPPORT
if (flags & (1ULL << I40E_FILTER_PCTYPE_NONF_IPV4_TCP_SYN_NO_ACK))
rss_hf |= ETH_RSS_NONFRAG_IPV4_TCP;
-#endif
if (flags & (1ULL << I40E_FILTER_PCTYPE_NONF_IPV4_UDP))
rss_hf |= ETH_RSS_NONFRAG_IPV4_UDP;
-#ifdef X722_SUPPORT
if (flags & (1ULL << I40E_FILTER_PCTYPE_NONF_UNICAST_IPV4_UDP))
rss_hf |= ETH_RSS_NONFRAG_IPV4_UDP;
if (flags & (1ULL << I40E_FILTER_PCTYPE_NONF_MULTICAST_IPV4_UDP))
rss_hf |= ETH_RSS_NONFRAG_IPV4_UDP;
-#endif
if (flags & (1ULL << I40E_FILTER_PCTYPE_NONF_IPV4_SCTP))
rss_hf |= ETH_RSS_NONFRAG_IPV4_SCTP;
if (flags & (1ULL << I40E_FILTER_PCTYPE_NONF_IPV4_OTHER))
@@ -6218,18 +6214,14 @@ i40e_parse_hena(uint64_t flags)
rss_hf |= ETH_RSS_FRAG_IPV6;
if (flags & (1ULL << I40E_FILTER_PCTYPE_NONF_IPV6_TCP))
rss_hf |= ETH_RSS_NONFRAG_IPV6_TCP;
-#ifdef X722_SUPPORT
if (flags & (1ULL << I40E_FILTER_PCTYPE_NONF_IPV6_TCP_SYN_NO_ACK))
rss_hf |= ETH_RSS_NONFRAG_IPV6_TCP;
-#endif
if (flags & (1ULL << I40E_FILTER_PCTYPE_NONF_IPV6_UDP))
rss_hf |= ETH_RSS_NONFRAG_IPV6_UDP;
-#ifdef X722_SUPPORT
if (flags & (1ULL << I40E_FILTER_PCTYPE_NONF_UNICAST_IPV6_UDP))
rss_hf |= ETH_RSS_NONFRAG_IPV6_UDP;
if (flags & (1ULL << I40E_FILTER_PCTYPE_NONF_MULTICAST_IPV6_UDP))
rss_hf |= ETH_RSS_NONFRAG_IPV6_UDP;
-#endif
if (flags & (1ULL << I40E_FILTER_PCTYPE_NONF_IPV6_SCTP))
rss_hf |= ETH_RSS_NONFRAG_IPV6_SCTP;
if (flags & (1ULL << I40E_FILTER_PCTYPE_NONF_IPV6_OTHER))
@@ -7101,7 +7093,6 @@ i40e_get_valid_input_set(enum i40e_filter_pctype pctype,
I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT |
I40E_INSET_FLEX_PAYLOAD,
-#ifdef X722_SUPPORT
[I40E_FILTER_PCTYPE_NONF_UNICAST_IPV4_UDP] =
I40E_INSET_DMAC | I40E_INSET_SMAC |
I40E_INSET_VLAN_OUTER | I40E_INSET_VLAN_INNER |
@@ -7120,7 +7111,6 @@ i40e_get_valid_input_set(enum i40e_filter_pctype pctype,
I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT |
I40E_INSET_FLEX_PAYLOAD,
-#endif
[I40E_FILTER_PCTYPE_NONF_IPV4_TCP] =
I40E_INSET_DMAC | I40E_INSET_SMAC |
I40E_INSET_VLAN_OUTER | I40E_INSET_VLAN_INNER |
@@ -7130,7 +7120,6 @@ i40e_get_valid_input_set(enum i40e_filter_pctype pctype,
I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT |
I40E_INSET_TCP_FLAGS | I40E_INSET_FLEX_PAYLOAD,
-#ifdef X722_SUPPORT
[I40E_FILTER_PCTYPE_NONF_IPV4_TCP_SYN_NO_ACK] =
I40E_INSET_DMAC | I40E_INSET_SMAC |
I40E_INSET_VLAN_OUTER | I40E_INSET_VLAN_INNER |
@@ -7140,7 +7129,6 @@ i40e_get_valid_input_set(enum i40e_filter_pctype pctype,
I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT |
I40E_INSET_TCP_FLAGS | I40E_INSET_FLEX_PAYLOAD,
-#endif
[I40E_FILTER_PCTYPE_NONF_IPV4_SCTP] =
I40E_INSET_DMAC | I40E_INSET_SMAC |
I40E_INSET_VLAN_OUTER | I40E_INSET_VLAN_INNER |
@@ -7174,7 +7162,6 @@ i40e_get_valid_input_set(enum i40e_filter_pctype pctype,
I40E_INSET_IPV6_HOP_LIMIT | I40E_INSET_IPV6_SRC |
I40E_INSET_IPV6_DST | I40E_INSET_SRC_PORT |
I40E_INSET_DST_PORT | I40E_INSET_FLEX_PAYLOAD,
-#ifdef X722_SUPPORT
[I40E_FILTER_PCTYPE_NONF_UNICAST_IPV6_UDP] =
I40E_INSET_DMAC | I40E_INSET_SMAC |
I40E_INSET_VLAN_OUTER | I40E_INSET_VLAN_INNER |
@@ -7193,7 +7180,6 @@ i40e_get_valid_input_set(enum i40e_filter_pctype pctype,
I40E_INSET_IPV6_DST | I40E_INSET_SRC_PORT |
I40E_INSET_DST_PORT | I40E_INSET_TCP_FLAGS |
I40E_INSET_FLEX_PAYLOAD,
-#endif
[I40E_FILTER_PCTYPE_NONF_IPV6_TCP] =
I40E_INSET_DMAC | I40E_INSET_SMAC |
I40E_INSET_VLAN_OUTER | I40E_INSET_VLAN_INNER |
@@ -7203,7 +7189,6 @@ i40e_get_valid_input_set(enum i40e_filter_pctype pctype,
I40E_INSET_IPV6_DST | I40E_INSET_SRC_PORT |
I40E_INSET_DST_PORT | I40E_INSET_TCP_FLAGS |
I40E_INSET_FLEX_PAYLOAD,
-#ifdef X722_SUPPORT
[I40E_FILTER_PCTYPE_NONF_IPV6_TCP_SYN_NO_ACK] =
I40E_INSET_DMAC | I40E_INSET_SMAC |
I40E_INSET_VLAN_OUTER | I40E_INSET_VLAN_INNER |
@@ -7213,7 +7198,6 @@ i40e_get_valid_input_set(enum i40e_filter_pctype pctype,
I40E_INSET_IPV6_DST | I40E_INSET_SRC_PORT |
I40E_INSET_DST_PORT | I40E_INSET_TCP_FLAGS |
I40E_INSET_FLEX_PAYLOAD,
-#endif
[I40E_FILTER_PCTYPE_NONF_IPV6_SCTP] =
I40E_INSET_DMAC | I40E_INSET_SMAC |
I40E_INSET_VLAN_OUTER | I40E_INSET_VLAN_INNER |
@@ -7253,7 +7237,6 @@ i40e_get_valid_input_set(enum i40e_filter_pctype pctype,
I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
I40E_INSET_IPV4_TOS | I40E_INSET_IPV4_TTL |
I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT,
-#ifdef X722_SUPPORT
[I40E_FILTER_PCTYPE_NONF_UNICAST_IPV4_UDP] =
I40E_INSET_VLAN_OUTER | I40E_INSET_VLAN_INNER |
I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
@@ -7264,19 +7247,16 @@ i40e_get_valid_input_set(enum i40e_filter_pctype pctype,
I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
I40E_INSET_IPV4_TOS | I40E_INSET_IPV4_TTL |
I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT,
-#endif
[I40E_FILTER_PCTYPE_NONF_IPV4_TCP] =
I40E_INSET_VLAN_OUTER | I40E_INSET_VLAN_INNER |
I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
I40E_INSET_IPV4_TOS | I40E_INSET_IPV4_TTL |
I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT,
-#ifdef X722_SUPPORT
[I40E_FILTER_PCTYPE_NONF_IPV4_TCP_SYN_NO_ACK] =
I40E_INSET_VLAN_OUTER | I40E_INSET_VLAN_INNER |
I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
I40E_INSET_IPV4_TOS | I40E_INSET_IPV4_TTL |
I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT,
-#endif
[I40E_FILTER_PCTYPE_NONF_IPV4_SCTP] =
I40E_INSET_VLAN_OUTER | I40E_INSET_VLAN_INNER |
I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
@@ -7298,7 +7278,6 @@ i40e_get_valid_input_set(enum i40e_filter_pctype pctype,
I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST |
I40E_INSET_IPV6_TC | I40E_INSET_IPV6_HOP_LIMIT |
I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT,
-#ifdef X722_SUPPORT
[I40E_FILTER_PCTYPE_NONF_UNICAST_IPV6_UDP] =
I40E_INSET_VLAN_OUTER | I40E_INSET_VLAN_INNER |
I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST |
@@ -7309,19 +7288,16 @@ i40e_get_valid_input_set(enum i40e_filter_pctype pctype,
I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST |
I40E_INSET_IPV6_TC | I40E_INSET_IPV6_HOP_LIMIT |
I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT,
-#endif
[I40E_FILTER_PCTYPE_NONF_IPV6_TCP] =
I40E_INSET_VLAN_OUTER | I40E_INSET_VLAN_INNER |
I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST |
I40E_INSET_IPV6_TC | I40E_INSET_IPV6_HOP_LIMIT |
I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT,
-#ifdef X722_SUPPORT
[I40E_FILTER_PCTYPE_NONF_IPV6_TCP_SYN_NO_ACK] =
I40E_INSET_VLAN_OUTER | I40E_INSET_VLAN_INNER |
I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST |
I40E_INSET_IPV6_TC | I40E_INSET_IPV6_HOP_LIMIT |
I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT,
-#endif
[I40E_FILTER_PCTYPE_NONF_IPV6_SCTP] =
I40E_INSET_VLAN_OUTER | I40E_INSET_VLAN_INNER |
I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST |
@@ -7374,22 +7350,18 @@ i40e_get_default_input_set(uint16_t pctype)
[I40E_FILTER_PCTYPE_NONF_IPV4_UDP] =
I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT,
-#ifdef X722_SUPPORT
[I40E_FILTER_PCTYPE_NONF_UNICAST_IPV4_UDP] =
I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT,
[I40E_FILTER_PCTYPE_NONF_MULTICAST_IPV4_UDP] =
I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT,
-#endif
[I40E_FILTER_PCTYPE_NONF_IPV4_TCP] =
I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT,
-#ifdef X722_SUPPORT
[I40E_FILTER_PCTYPE_NONF_IPV4_TCP_SYN_NO_ACK] =
I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT,
-#endif
[I40E_FILTER_PCTYPE_NONF_IPV4_SCTP] =
I40E_INSET_IPV4_SRC | I40E_INSET_IPV4_DST |
I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT |
@@ -7401,22 +7373,18 @@ i40e_get_default_input_set(uint16_t pctype)
[I40E_FILTER_PCTYPE_NONF_IPV6_UDP] =
I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST |
I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT,
-#ifdef X722_SUPPORT
[I40E_FILTER_PCTYPE_NONF_UNICAST_IPV6_UDP] =
I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST |
I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT,
[I40E_FILTER_PCTYPE_NONF_MULTICAST_IPV6_UDP] =
I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST |
I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT,
-#endif
[I40E_FILTER_PCTYPE_NONF_IPV6_TCP] =
I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST |
I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT,
-#ifdef X722_SUPPORT
[I40E_FILTER_PCTYPE_NONF_IPV6_TCP_SYN_NO_ACK] =
I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST |
I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT,
-#endif
[I40E_FILTER_PCTYPE_NONF_IPV6_SCTP] =
I40E_INSET_IPV6_SRC | I40E_INSET_IPV6_DST |
I40E_INSET_SRC_PORT | I40E_INSET_DST_PORT |
@@ -8215,18 +8183,14 @@ i40e_pctype_to_flowtype(enum i40e_filter_pctype pctype)
[I40E_FILTER_PCTYPE_FRAG_IPV4] = RTE_ETH_FLOW_FRAG_IPV4,
[I40E_FILTER_PCTYPE_NONF_IPV4_UDP] =
RTE_ETH_FLOW_NONFRAG_IPV4_UDP,
-#ifdef X722_SUPPORT
[I40E_FILTER_PCTYPE_NONF_UNICAST_IPV4_UDP] =
RTE_ETH_FLOW_NONFRAG_IPV4_UDP,
[I40E_FILTER_PCTYPE_NONF_MULTICAST_IPV4_UDP] =
RTE_ETH_FLOW_NONFRAG_IPV4_UDP,
-#endif
[I40E_FILTER_PCTYPE_NONF_IPV4_TCP] =
RTE_ETH_FLOW_NONFRAG_IPV4_TCP,
-#ifdef X722_SUPPORT
[I40E_FILTER_PCTYPE_NONF_IPV4_TCP_SYN_NO_ACK] =
RTE_ETH_FLOW_NONFRAG_IPV4_TCP,
-#endif
[I40E_FILTER_PCTYPE_NONF_IPV4_SCTP] =
RTE_ETH_FLOW_NONFRAG_IPV4_SCTP,
[I40E_FILTER_PCTYPE_NONF_IPV4_OTHER] =
@@ -8234,18 +8198,14 @@ i40e_pctype_to_flowtype(enum i40e_filter_pctype pctype)
[I40E_FILTER_PCTYPE_FRAG_IPV6] = RTE_ETH_FLOW_FRAG_IPV6,
[I40E_FILTER_PCTYPE_NONF_IPV6_UDP] =
RTE_ETH_FLOW_NONFRAG_IPV6_UDP,
-#ifdef X722_SUPPORT
[I40E_FILTER_PCTYPE_NONF_UNICAST_IPV6_UDP] =
RTE_ETH_FLOW_NONFRAG_IPV6_UDP,
[I40E_FILTER_PCTYPE_NONF_MULTICAST_IPV6_UDP] =
RTE_ETH_FLOW_NONFRAG_IPV6_UDP,
-#endif
[I40E_FILTER_PCTYPE_NONF_IPV6_TCP] =
RTE_ETH_FLOW_NONFRAG_IPV6_TCP,
-#ifdef X722_SUPPORT
[I40E_FILTER_PCTYPE_NONF_IPV6_TCP_SYN_NO_ACK] =
RTE_ETH_FLOW_NONFRAG_IPV6_TCP,
-#endif
[I40E_FILTER_PCTYPE_NONF_IPV6_SCTP] =
RTE_ETH_FLOW_NONFRAG_IPV6_SCTP,
[I40E_FILTER_PCTYPE_NONF_IPV6_OTHER] =
--
2.4.11
^ permalink raw reply related
* Re: dpdk/vpp and cross-version migration for vhost
From: Daniel P. Berrange @ 2016-12-09 14:42 UTC (permalink / raw)
To: Maxime Coquelin
Cc: Yuanhan Liu, Michael S. Tsirkin, dev, qemu-devel,
Stephen Hemminger, libvir-list, vpp-dev, Marc-André Lureau
In-Reply-To: <9b73a012-fb7a-4b7c-0dfe-6ef4b8cb48d2@redhat.com>
On Fri, Dec 09, 2016 at 02:35:58PM +0100, Maxime Coquelin wrote:
> ++Daniel for libvirt
>
> On 11/24/2016 07:31 AM, Yuanhan Liu wrote:
> > > > > > > > > As version here is an opaque string for libvirt and qemu,
> > > > > > > > > > > > > > >>anything can be used - but I suggest either a list
> > > > > > > > > > > > > > >>of values defining the interface, e.g.
> > > > > > > > > > > > > > >>any_layout=on,max_ring=256
> > > > > > > > > > > > > > >>or a version including the name and vendor of the backend,
> > > > > > > > > > > > > > >>e.g. "org.dpdk.v4.5.6".
> > > > > >
> > > > > > The version scheme may not be ideal here. Assume a QEMU is supposed
> > > > > > to work with a specific DPDK version, however, user may disable some
> > > > > > newer features through qemu command line, that it also could work with
> > > > > > an elder DPDK version. Using the version scheme will not allow us doing
> > > > > > such migration to an elder DPDK version. The MTU is a lively example
> > > > > > here? (when MTU feature is provided by QEMU but is actually disabled
> > > > > > by user, that it could also work with an elder DPDK without MTU support).
> > > > > >
> > > > > > --yliu
> > > >
> > > > OK, so does a list of values look better to you then?
> > Yes, if there are no better way.
> >
> > And I think it may be better to not list all those features, literally.
> > But instead, using the number should be better, say, features=0xdeadbeef.
> >
> > Listing the feature names means we have to come to an agreement in all
> > components involved here (QEMU, libvirt, DPDK, VPP, and maybe more
> > backends), that we have to use the exact same feature names. Though it
> > may not be a big deal, it lacks some flexibility.
> >
> > A feature bits will not have this issue.
>
> I initially thought having key/value pairs would be more flexible, and
> could allow migrating to another application if compatible (i.e. from
> OVS to VPP, and vice versa...) without needing synchronization between
> the applications.
>
> But Daniel pointed me out that it would add a lot of complexity on
> management tool side, as it would need to know how to interpret these
> key/value pairs. I think his argument is very valid.
>
> So maybe the best way would be the version string, letting the
> application (OVS-DPDK/VPP/...) specify which version it is
> compatible with.
> For the downsides, as soon as a new feature is supported in vhost-user
> application, the new version will not be advertised as compatible with
> the previous one, even if the user disables the feature in Qemu (as
> pointed out by Yuanhan).
We need two distinct capabilities in order to make this work properly.
First, libvirt needs to be able to query the list of (one or more)
supported versions strings for a given host.
Second, when launching QEMU we need to be able to specify the desired
version against the NIC backend.
So, consider host A, initially supporting "ovsdpdk-v1". When libvirt
launches the VM it will specify 'ovsdpgk-v1' as the desired version
string to use.
Now some time later you add features X, Y & Z to a new release of
DPDK and install this on host B. Host B is able to support two
versions 'ovsdppk-v1' and 'ovsdpdk-v2'. When libvirt launches
a VM on host B, it'll pick 'ovsdpgk-v2' by default, since that's
the newest. When libvirt migrates a VM from host A, however,
it will request the old version 'ovsdpdk-v1' in order to ensure
compatibility. Similarly when launching a new VM on host B,
libvirt could choose to use 'ovsdpdk-v1' as the version, in
order to enable migration to the olver host A, if desired.
This is exactly the way QEMU machine types work, hiding the
existance of 100's low level settings / default values, that
a mgmt app would otherwise have to worry about.
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :|
^ permalink raw reply
* Re: [PATCH v2 1/6] eventdev: introduce event driven programming model
From: Bruce Richardson @ 2016-12-09 15:11 UTC (permalink / raw)
To: Jerin Jacob
Cc: dev, thomas.monjalon, hemant.agrawal, gage.eads, harry.van.haaren
In-Reply-To: <20161208204115.GA13798@svelivela-lt.caveonetworks.com>
On Fri, Dec 09, 2016 at 02:11:15AM +0530, Jerin Jacob wrote:
> On Thu, Dec 08, 2016 at 09:30:49AM +0000, Bruce Richardson wrote:
> > On Thu, Dec 08, 2016 at 12:23:03AM +0530, Jerin Jacob wrote:
> > > On Tue, Dec 06, 2016 at 04:51:19PM +0000, Bruce Richardson wrote:
> > > > On Tue, Dec 06, 2016 at 09:22:15AM +0530, Jerin Jacob wrote:
> > > > > In a polling model, lcores poll ethdev ports and associated
> > > > > rx queues directly to look for packet. In an event driven model,
> > > > > by contrast, lcores call the scheduler that selects packets for
> > > > > them based on programmer-specified criteria. Eventdev library
> > > > > adds support for event driven programming model, which offer
> > > > > applications automatic multicore scaling, dynamic load balancing,
> > > > > pipelining, packet ingress order maintenance and
> > > > > synchronization services to simplify application packet processing.
> > > > >
> > > > > By introducing event driven programming model, DPDK can support
> > > > > both polling and event driven programming models for packet processing,
> > > > > and applications are free to choose whatever model
> > > > > (or combination of the two) that best suits their needs.
> > > > >
> > > > > This patch adds the eventdev specification header file.
> > > > >
> > > > > Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> > > > > ---
> > > > > + /** WORD1 */
> > > > > + RTE_STD_C11
> > > > > + union {
> > > > > + uint64_t u64;
> > > > > + /**< Opaque 64-bit value */
> > > > > + uintptr_t event_ptr;
> > > > > + /**< Opaque event pointer */
> > > >
> > > > Since we have a uint64_t member of the union, might this be better as a
> > > > void * rather than uintptr_t?
> > >
> > > No strong opinion here. For me, uintptr_t looks clean.
> > > But, It is OK to change to void* as per your input.
> > >
> > > >
> > > > > + struct rte_mbuf *mbuf;
> > > > > + /**< mbuf pointer if dequeued event is associated with mbuf */
> > > > > + };
> > > > > +};
> > > > > +
> > > > <snip>
> > > > > +/**
> > > > > + * Link multiple source event queues supplied in *rte_event_queue_link*
> > > > > + * structure as *queue_id* to the destination event port designated by its
> > > > > + * *port_id* on the event device designated by its *dev_id*.
> > > > > + *
> > > > > + * The link establishment shall enable the event port *port_id* from
> > > > > + * receiving events from the specified event queue *queue_id*
> > > > > + *
> > > > > + * An event queue may link to one or more event ports.
> > > > > + * The number of links can be established from an event queue to event port is
> > > > > + * implementation defined.
> > > > > + *
> > > > > + * Event queue(s) to event port link establishment can be changed at runtime
> > > > > + * without re-configuring the device to support scaling and to reduce the
> > > > > + * latency of critical work by establishing the link with more event ports
> > > > > + * at runtime.
> > > >
> > > > I think this might need to be clarified. The device doesn't need to be
> > > > reconfigured, but does it need to be stopped? In SW implementation, this
> > > > affects how much we have to make things thread-safe. At minimum I think
> > > > we should limit this to having only one thread call the function at a
> > > > time, but we may allow enqueue dequeue ops from the data plane to run
> > > > in parallel.
> > >
> > > Cavium implementation can change it at runtime without re-configuring or stopping
> > > the device to support runtime load balancing from the application perspective.
> > >
> > > AFAIK, link establishment is _NOT_ fast path API. But the application
> > > can invoke it from worker thread whenever there is a need for re-wiring
> > > the queue to port connection for better explicit load balancing. IMO, A
> > > software implementation with lock is fine here as we don't use this in
> > > fastpath.
> > >
> > > Thoughts?
> > > >
> >
> > I agree that it's obviously not fast-path. Therefore I suggest that we
> > document that this API should be safe to call while the data path is in
> > operation, but that it should not be called by multiple cores
> > simultaneously i.e. single-writer, multi-reader safe, but not
> > multi-writer safe. Does that seem reasonable to you?
>
> If I understand it correctly, per "event port" their will be ONLY ONE
> writer at time.
>
> i.e, In the valid case, Following two can be invoked in parallel
> rte_event_port_link(dev_id, 0 /*port_id*/,..)
> rte_event_port_link(dev_id, 1 /*port_id*/,..)
>
> But, not invoking rte_event_port_link() on the _same_ event port in parallel
>
> Are we on same page?
>
> Jerin
>
Not entirely. Since our current software implementation pushes the events
from the internal queues to the ports, rather than having the ports pull
the events, the links are tracked at the qid level rather than at the
port one. So having two link operations on two separate ports at the
same time could actually conflict for us, because they attempt to modify
the mappings for the same queue. That's why for us the number of
simultaneous link calls is important.
However, given that this is not fast-path, we can probably work around
this with locking internally. The main ask is that we explicitly
document what are the expected safe and unsafe conditions under which
this call can be made.
/Bruce
^ permalink raw reply
* Re: [PATCH v4] eal: restrict cores auto detection
From: Bruce Richardson @ 2016-12-09 15:14 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: Jianfeng Tan, dev, david.marchand, pmatilai
In-Reply-To: <1697449.uzq8KWsvfF@xps13>
On Thu, Dec 08, 2016 at 07:19:41PM +0100, Thomas Monjalon wrote:
> 2016-12-02 17:48, Jianfeng Tan:
> > This patch uses pthread_getaffinity_np() to narrow down used
> > cores when none of below options is specified:
> > * coremask (-c)
> > * corelist (-l)
> > * and coremap (--lcores)
> >
> > The purpose of this patch is to leave out these core related options
> > when DPDK applications are deployed under container env, so that
> > users do not need decide the core related parameters when developing
> > applications. Instead, when applications are deployed in containers,
> > use cpu-set to constrain which cores can be used inside this container
> > instance. And DPDK application inside containers just rely on this
> > auto detect mechanism to start polling threads.
> >
> > Note: previously, some users are using isolated CPUs, which could
> > be excluded by default. Please add commands like taskset to use
> > those cores.
> >
> > Test example:
> > $ taskset 0xc0000 ./examples/helloworld/build/helloworld -m 1024
>
> Bruce, what do you think of this version?
> It requires taskset only if -c, -l and --lcores are not used.
>
I'm fine with that since it maintains backward compatibilty for those
options.
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
^ permalink raw reply
* Re: [PATCH v1 0/4] app: make python apps python2/3 compliant
From: Neil Horman @ 2016-12-09 15:28 UTC (permalink / raw)
To: John McNamara; +Cc: dev, mkletzan
In-Reply-To: <1481212265-10229-1-git-send-email-john.mcnamara@intel.com>
On Thu, Dec 08, 2016 at 03:51:01PM +0000, John McNamara wrote:
> These patches refactor the DPDK Python applications to make them Python 2/3
> compatible.
>
> In order to do this the patchset starts by making the apps PEP8 compliant in
> accordance with the DPDK Coding guidelines:
>
> http://dpdk.org/doc/guides/contributing/coding_style.html#python-code
>
> Implementing PEP8 and Python 2/3 compliance means that we can check all future
> Python patches for consistency. Python 2/3 support also makes downstream
> packaging easier as more distros move to Python 3 as the system python.
>
> See the previous discussion about Python2/3 compatibilty here:
>
> http://dpdk.org/ml/archives/dev/2016-December/051683.html
>
> I've tested that the apps compile with python 2 and 3 and I've tested some
> of the apps for consistent output but it needs additional testing.
>
> John McNamara (4):
> app: make python apps pep8 compliant
> app: make python apps python2/3 compliant
> app: give python apps a consistent shebang line
> doc: add required python versions to coding guidelines
>
> app/cmdline_test/cmdline_test.py | 87 ++-
> app/cmdline_test/cmdline_test_data.py | 403 +++++-----
> app/test/autotest.py | 46 +-
> app/test/autotest_data.py | 831 +++++++++++----------
> app/test/autotest_runner.py | 740 +++++++++---------
> app/test/autotest_test_funcs.py | 481 ++++++------
> doc/guides/conf.py | 11 +-
> doc/guides/contributing/coding_style.rst | 3 +-
> examples/ip_pipeline/config/diagram-generator.py | 13 +-
> .../ip_pipeline/config/pipeline-to-core-mapping.py | 11 +-
> tools/cpu_layout.py | 79 +-
> tools/dpdk-devbind.py | 26 +-
> tools/dpdk-pmdinfo.py | 73 +-
> 13 files changed, 1410 insertions(+), 1394 deletions(-)
>
> --
> 2.7.4
>
I think the changelog is deceptive. It claims to make all the utilities python2
and 3 compliant. But compliance with python3 is more than just stylistic
formatting. After this series several of these apps continue to fail under
python3. dpdk-pmdinfo as an example:
[nhorman@hmsreliant dpdk]$ ./tools/dpdk-pmdinfo.py ./build/app/testacl
Traceback (most recent call last):
File "./tools/dpdk-pmdinfo.py", line 607, in <module>
main()
File "./tools/dpdk-pmdinfo.py", line 596, in main
readelf.process_dt_needed_entries()
File "./tools/dpdk-pmdinfo.py", line 437, in process_dt_needed_entries
rc = tag.needed.find("librte_pmd")
TypeError: a bytes-like object is required, not 'str'
I'm not saying its a bad patchset, but the changelog should reflect that the
change is purely stylistic, not functional.
Neil
^ permalink raw reply
* [PATCH v2] crypto/qat: fix to avoid buffer overwrite in OOP case
From: Fiona Trahe @ 2016-12-09 15:39 UTC (permalink / raw)
To: dev; +Cc: pablo.de.lara.guarch, fiona.trahe, stable
In-Reply-To: <1479986267-2836-1-git-send-email-fiona.trahe@intel.com>
In out-of-place operation, data is DMAed from source mbuf
to destination mbuf. To avoid header data in dest mbuf being
overwritten, the minimal data-set should be DMAed.
Fixes: 39e0bee48e81 ("crypto/qat: rework request builder for performance")
Signed-off-by: Fiona Trahe <fiona.trahe@intel.com>
CC: stable@dpdk.org
---
This patch depends on following patch :
crypto: remove unused digest-appended feature
http://dpdk.org/dev/patchwork/patch/17079/
v2:
- included ref for stable
drivers/crypto/qat/qat_crypto.c | 66 ++++++++++++++++++++---------------------
drivers/crypto/qat/qat_crypto.h | 1 +
2 files changed, 34 insertions(+), 33 deletions(-)
diff --git a/drivers/crypto/qat/qat_crypto.c b/drivers/crypto/qat/qat_crypto.c
index 6a6bd2e..afce4ac 100644
--- a/drivers/crypto/qat/qat_crypto.c
+++ b/drivers/crypto/qat/qat_crypto.c
@@ -955,7 +955,7 @@ qat_write_hw_desc_entry(struct rte_crypto_op *op, uint8_t *out_msg)
uint32_t cipher_len = 0, cipher_ofs = 0;
uint32_t auth_len = 0, auth_ofs = 0;
uint32_t min_ofs = 0;
- uint64_t buf_start = 0;
+ uint64_t src_buf_start = 0, dst_buf_start = 0;
#ifdef RTE_LIBRTE_PMD_QAT_DEBUG_TX
@@ -1077,27 +1077,40 @@ qat_write_hw_desc_entry(struct rte_crypto_op *op, uint8_t *out_msg)
if (do_cipher && do_auth)
min_ofs = cipher_ofs < auth_ofs ? cipher_ofs : auth_ofs;
-
- /* Start DMA at nearest aligned address below min_ofs */
- #define QAT_64_BTYE_ALIGN_MASK (~0x3f)
- buf_start = rte_pktmbuf_mtophys_offset(op->sym->m_src, min_ofs) &
- QAT_64_BTYE_ALIGN_MASK;
-
- if (unlikely((rte_pktmbuf_mtophys(op->sym->m_src)
- - rte_pktmbuf_headroom(op->sym->m_src)) > buf_start)) {
- /* alignment has pushed addr ahead of start of mbuf
- * so revert and take the performance hit
+ if (unlikely(op->sym->m_dst != NULL)) {
+ /* Out-of-place operation (OOP)
+ * Don't align DMA start. DMA the minimum data-set
+ * so as not to overwrite data in dest buffer
*/
- buf_start = rte_pktmbuf_mtophys(op->sym->m_src);
+ src_buf_start =
+ rte_pktmbuf_mtophys_offset(op->sym->m_src, min_ofs);
+ dst_buf_start =
+ rte_pktmbuf_mtophys_offset(op->sym->m_dst, min_ofs);
+ } else {
+ /* In-place operation
+ * Start DMA at nearest aligned address below min_ofs
+ */
+ src_buf_start =
+ rte_pktmbuf_mtophys_offset(op->sym->m_src, min_ofs)
+ & QAT_64_BTYE_ALIGN_MASK;
+
+ if (unlikely((rte_pktmbuf_mtophys(op->sym->m_src) -
+ rte_pktmbuf_headroom(op->sym->m_src))
+ > src_buf_start)) {
+ /* alignment has pushed addr ahead of start of mbuf
+ * so revert and take the performance hit
+ */
+ src_buf_start =
+ rte_pktmbuf_mtophys_offset(op->sym->m_src,
+ min_ofs);
+ }
+ dst_buf_start = src_buf_start;
}
- qat_req->comn_mid.dest_data_addr =
- qat_req->comn_mid.src_data_addr = buf_start;
-
if (do_cipher) {
cipher_param->cipher_offset =
- (uint32_t)rte_pktmbuf_mtophys_offset(
- op->sym->m_src, cipher_ofs) - buf_start;
+ (uint32_t)rte_pktmbuf_mtophys_offset(
+ op->sym->m_src, cipher_ofs) - src_buf_start;
cipher_param->cipher_length = cipher_len;
} else {
cipher_param->cipher_offset = 0;
@@ -1105,7 +1118,7 @@ qat_write_hw_desc_entry(struct rte_crypto_op *op, uint8_t *out_msg)
}
if (do_auth) {
auth_param->auth_off = (uint32_t)rte_pktmbuf_mtophys_offset(
- op->sym->m_src, auth_ofs) - buf_start;
+ op->sym->m_src, auth_ofs) - src_buf_start;
auth_param->auth_len = auth_len;
} else {
auth_param->auth_off = 0;
@@ -1118,21 +1131,8 @@ qat_write_hw_desc_entry(struct rte_crypto_op *op, uint8_t *out_msg)
(cipher_param->cipher_offset + cipher_param->cipher_length)
: (auth_param->auth_off + auth_param->auth_len);
-
- /* out-of-place operation (OOP) */
- if (unlikely(op->sym->m_dst != NULL)) {
-
- if (do_auth)
- qat_req->comn_mid.dest_data_addr =
- rte_pktmbuf_mtophys_offset(op->sym->m_dst,
- auth_ofs)
- - auth_param->auth_off;
- else
- qat_req->comn_mid.dest_data_addr =
- rte_pktmbuf_mtophys_offset(op->sym->m_dst,
- cipher_ofs)
- - cipher_param->cipher_offset;
- }
+ qat_req->comn_mid.src_data_addr = src_buf_start;
+ qat_req->comn_mid.dest_data_addr = dst_buf_start;
if (ctx->qat_hash_alg == ICP_QAT_HW_AUTH_ALGO_GALOIS_128 ||
ctx->qat_hash_alg == ICP_QAT_HW_AUTH_ALGO_GALOIS_64) {
diff --git a/drivers/crypto/qat/qat_crypto.h b/drivers/crypto/qat/qat_crypto.h
index 0afe74e..6b84488 100644
--- a/drivers/crypto/qat/qat_crypto.h
+++ b/drivers/crypto/qat/qat_crypto.h
@@ -43,6 +43,7 @@
*/
#define ALIGN_POW2_ROUNDUP(num, align) \
(((num) + (align) - 1) & ~((align) - 1))
+#define QAT_64_BTYE_ALIGN_MASK (~0x3f)
/**
* Structure associated with each queue.
--
2.5.0
^ permalink raw reply related
* Re: [PATCH v2 00/31] net/i40e: base code update
From: Ferruh Yigit @ 2016-12-09 16:08 UTC (permalink / raw)
To: Jingjing Wu, dev; +Cc: helin.zhang
In-Reply-To: <1481294364-83505-1-git-send-email-jingjing.wu@intel.com>
On 12/9/2016 2:38 PM, Jingjing Wu wrote:
> i40e base code upate. The main changes are:
> - add clause22 and clause45 implementation for PHY registers accessing
> - replace existing legacy memcpy() calls with i40e_memcpy() calls.
> - use BIT() macro instead of bit fields
> - add clear all WoL filters implementation
> - add ERROR state for NVM update state machine
> - add broadcast promiscuous control per VLAN
> - remove unused X722_SUPPORT and I40E_NDIS_SUPPORT MARCOs
>
> v2 changes:
> - comments rework
> - complie issue fix
> - rebase to dpdk-next-net
>
> Jingjing Wu (31):
> net/i40e/base: add encap csum VF offload flag
> net/i40e/base: preserve extended PHY type field
> net/i40e/base: remove unnecessary code
> net/i40e/base: fix bit test mask
> net/i40e/base: group base mode VF offload flags
> net/i40e/base: fix long link down notification time
> net/i40e/base: add media type detection for 25G link
> net/i40e/base: add clause22 and clause45 implementation
> net/i40e/base: add bus number info
> net/i40e/base: add protocols when discover capabilities
> net/i40e/base: pass unknown PHY type for unknown PHYs
> net/i40e/base: replace memcpy
> net/i40e/base: deprecating unused macro
> net/i40e/base: remove FPK HyperV VF device ID
> net/i40e/base: add FEC bits to PHY capabilities
> net/i40e/base: use BIT() macro instead of bit fields
> net/i40e/base: adjust 25G PHY type values
> net/i40e/base: implement clear all WoL filters
> net/i40e/base: implement set VSI full promisc mode
> net/i40e/base: add defines for new aq command
> net/i40e/base: save link FEC info from link up event
> net/i40e/base: acquire NVM lock before reads on all devices
> net/i40e/base: change shift values to hex
> net/i40e/base: comment that udp port must be in Host order
> net/i40e/base: remove duplicate definitions
> net/i40e/base: add ERROR state for NVM update state machine
> net/i40e/base: add broadcast promiscuous control per VLAN
> net/i40e/base: avoid division by zero
> net/i40e/base: fix byte order
> net/i40e/base: remove unused macro
> net/i40e: remove unused macro from PMD
>
Overall patches looks good, thanks.
But according comment logs, following patches can be for fixing
something broken in the existing code, can you please check, if so can
you please update commit logs according [1]?
[PATCH v2 02/31] net/i40e/base: preserve extended PHY type field
[PATCH v2 11/31] net/i40e/base: pass unknown PHY type for unknown PHYs
[PATCH v2 20/31] net/i40e/base: add defines for new aq command
[PATCH v2 22/31] net/i40e/base: acquire NVM lock before reads on all devices
[PATCH v2 28/31] net/i40e/base: avoid division by zero
Thanks,
ferruh
[1]
Updating patch title to point the fix, adding fixes tag and CC: stable tree.
^ permalink raw reply
* Re: [PATCH 01/22] ethdev: introduce generic flow API
From: Adrien Mazarguil @ 2016-12-09 16:38 UTC (permalink / raw)
To: Chandran, Sugesh
Cc: Kevin Traynor, dev@dpdk.org, Thomas Monjalon,
De Lara Guarch, Pablo, Olivier Matz, sugesh.chandran@intel.comn
In-Reply-To: <2EF2F5C0CC56984AA024D0B180335FCB13EC4696@IRSMSX102.ger.corp.intel.com>
Hi Sugesh,
On Fri, Dec 09, 2016 at 12:18:03PM +0000, Chandran, Sugesh wrote:
[...]
> > > Are you going to provide any control over the initialization of NIC
> > > to define the capability matrices For eg; To operate in a L3 router mode,
> > software wanted to initialize the NIC port only to consider the L2 and L3
> > fields.
> > > I assume the initialization is done based on the first rules that are
> > programmed into the NIC.?
> >
> > Precisely, PMDs are supposed to determine the most appropriate device
> > mode to use in order to handle the requested rules. They may even switch
> > to another mode if necessary assuming this does not break existing
> > constraints.
> >
> > I think we've discussed an atomic (commit-based) mode of operation
> > through separate functions as well, where the application would attempt to
> > create a bunch of rules at once, possibly making it easier for PMDs to
> > determine the most appropriate mode of operation for the device.
> >
> > All of these may be added later according to users feedback once the basic
> > API has settled.
> [Sugesh] Yes , we discussed about this before. However I feel that, it make sense
> to provide some flexibility to the user/application to define a profile/mode of the device.
> This way the complexity of determining the mode by itself will be taken away from PMD.
> Looking at the P4 enablement patches in OVS, the mode definition APIs can be used in conjunction
> P4 behavioral model.
> For eg: A P4 model for a L2 switch operate OVS as a L2 switch. Using the mode definition APIs
> Its possible to impose the same behavioral model in the hardware too.
> This way its simple, clean and very predictive though it needs to define an additional profile_define APIs.
> I am sorry to provide the comment at this stage, However looking at the adoption of ebpf, P4 make me
> to think this way.
> What do you think?
What you suggest (device profile configuration) would be done by a separate
function in any case, so as long as everyone agrees on a generic method to
do so, no problem with extending rte_flow. By default in the meantime we'll
have to rely on PMDs to make the right decision.
Do you think it has to be defined from the beginning?
--
Adrien Mazarguil
6WIND
^ permalink raw reply
* Re: dpdk/vpp and cross-version migration for vhost
From: Maxime Coquelin @ 2016-12-09 16:45 UTC (permalink / raw)
To: Daniel P. Berrange
Cc: Yuanhan Liu, Michael S. Tsirkin, dev, Stephen Hemminger,
qemu-devel, libvir-list, vpp-dev, Marc-André Lureau,
Flavio Leitner, Aaron Conole
In-Reply-To: <20161209144229.GC24165@redhat.com>
On 12/09/2016 03:42 PM, Daniel P. Berrange wrote:
> On Fri, Dec 09, 2016 at 02:35:58PM +0100, Maxime Coquelin wrote:
>> ++Daniel for libvirt
>>
>> On 11/24/2016 07:31 AM, Yuanhan Liu wrote:
>>>>>>>>>> As version here is an opaque string for libvirt and qemu,
>>>>>>>>>>>>>>>>> anything can be used - but I suggest either a list
>>>>>>>>>>>>>>>>> of values defining the interface, e.g.
>>>>>>>>>>>>>>>>> any_layout=on,max_ring=256
>>>>>>>>>>>>>>>>> or a version including the name and vendor of the backend,
>>>>>>>>>>>>>>>>> e.g. "org.dpdk.v4.5.6".
>>>>>>>
>>>>>>> The version scheme may not be ideal here. Assume a QEMU is supposed
>>>>>>> to work with a specific DPDK version, however, user may disable some
>>>>>>> newer features through qemu command line, that it also could work with
>>>>>>> an elder DPDK version. Using the version scheme will not allow us doing
>>>>>>> such migration to an elder DPDK version. The MTU is a lively example
>>>>>>> here? (when MTU feature is provided by QEMU but is actually disabled
>>>>>>> by user, that it could also work with an elder DPDK without MTU support).
>>>>>>>
>>>>>>> --yliu
>>>>>
>>>>> OK, so does a list of values look better to you then?
>>> Yes, if there are no better way.
>>>
>>> And I think it may be better to not list all those features, literally.
>>> But instead, using the number should be better, say, features=0xdeadbeef.
>>>
>>> Listing the feature names means we have to come to an agreement in all
>>> components involved here (QEMU, libvirt, DPDK, VPP, and maybe more
>>> backends), that we have to use the exact same feature names. Though it
>>> may not be a big deal, it lacks some flexibility.
>>>
>>> A feature bits will not have this issue.
>>
>> I initially thought having key/value pairs would be more flexible, and
>> could allow migrating to another application if compatible (i.e. from
>> OVS to VPP, and vice versa...) without needing synchronization between
>> the applications.
>>
>> But Daniel pointed me out that it would add a lot of complexity on
>> management tool side, as it would need to know how to interpret these
>> key/value pairs. I think his argument is very valid.
>>
>> So maybe the best way would be the version string, letting the
>> application (OVS-DPDK/VPP/...) specify which version it is
>> compatible with.
>> For the downsides, as soon as a new feature is supported in vhost-user
>> application, the new version will not be advertised as compatible with
>> the previous one, even if the user disables the feature in Qemu (as
>> pointed out by Yuanhan).
>
> We need two distinct capabilities in order to make this work properly.
>
> First, libvirt needs to be able to query the list of (one or more)
> supported versions strings for a given host.
Shouldn't be the role of OpenStack/Neutron? IIUC, libvirt knows nothing
about OVS.
> Second, when launching QEMU we need to be able to specify the desired
> version against the NIC backend.
>
> So, consider host A, initially supporting "ovsdpdk-v1". When libvirt
> launches the VM it will specify 'ovsdpgk-v1' as the desired version
> string to use.
>
> Now some time later you add features X, Y & Z to a new release of
> DPDK and install this on host B. Host B is able to support two
> versions 'ovsdppk-v1' and 'ovsdpdk-v2'. When libvirt launches
> a VM on host B, it'll pick 'ovsdpgk-v2' by default, since that's
> the newest. When libvirt migrates a VM from host A, however,
> it will request the old version 'ovsdpdk-v1' in order to ensure
> compatibility. Similarly when launching a new VM on host B,
> libvirt could choose to use 'ovsdpdk-v1' as the version, in
> order to enable migration to the olver host A, if desired.
>
> This is exactly the way QEMU machine types work, hiding the
> existance of 100's low level settings / default values, that
> a mgmt app would otherwise have to worry about.
I agree on the principle. I need to check what is missing for OVS to
support different versions on different vhost-user ports.
Thanks,
Maxime
>
> Regards,
> Daniel
>
^ permalink raw reply
* Re: dpdk/vpp and cross-version migration for vhost
From: Daniel P. Berrange @ 2016-12-09 16:48 UTC (permalink / raw)
To: Maxime Coquelin
Cc: Yuanhan Liu, Michael S. Tsirkin, dev, Stephen Hemminger,
qemu-devel, libvir-list, vpp-dev, Marc-André Lureau,
Flavio Leitner, Aaron Conole
In-Reply-To: <d182d88c-219a-c4ed-4119-a071f1926192@redhat.com>
On Fri, Dec 09, 2016 at 05:45:13PM +0100, Maxime Coquelin wrote:
>
>
> On 12/09/2016 03:42 PM, Daniel P. Berrange wrote:
> > On Fri, Dec 09, 2016 at 02:35:58PM +0100, Maxime Coquelin wrote:
> > > ++Daniel for libvirt
> > >
> > > On 11/24/2016 07:31 AM, Yuanhan Liu wrote:
> > > > > > > > > > > As version here is an opaque string for libvirt and qemu,
> > > > > > > > > > > > > > > > > > anything can be used - but I suggest either a list
> > > > > > > > > > > > > > > > > > of values defining the interface, e.g.
> > > > > > > > > > > > > > > > > > any_layout=on,max_ring=256
> > > > > > > > > > > > > > > > > > or a version including the name and vendor of the backend,
> > > > > > > > > > > > > > > > > > e.g. "org.dpdk.v4.5.6".
> > > > > > > >
> > > > > > > > The version scheme may not be ideal here. Assume a QEMU is supposed
> > > > > > > > to work with a specific DPDK version, however, user may disable some
> > > > > > > > newer features through qemu command line, that it also could work with
> > > > > > > > an elder DPDK version. Using the version scheme will not allow us doing
> > > > > > > > such migration to an elder DPDK version. The MTU is a lively example
> > > > > > > > here? (when MTU feature is provided by QEMU but is actually disabled
> > > > > > > > by user, that it could also work with an elder DPDK without MTU support).
> > > > > > > >
> > > > > > > > --yliu
> > > > > >
> > > > > > OK, so does a list of values look better to you then?
> > > > Yes, if there are no better way.
> > > >
> > > > And I think it may be better to not list all those features, literally.
> > > > But instead, using the number should be better, say, features=0xdeadbeef.
> > > >
> > > > Listing the feature names means we have to come to an agreement in all
> > > > components involved here (QEMU, libvirt, DPDK, VPP, and maybe more
> > > > backends), that we have to use the exact same feature names. Though it
> > > > may not be a big deal, it lacks some flexibility.
> > > >
> > > > A feature bits will not have this issue.
> > >
> > > I initially thought having key/value pairs would be more flexible, and
> > > could allow migrating to another application if compatible (i.e. from
> > > OVS to VPP, and vice versa...) without needing synchronization between
> > > the applications.
> > >
> > > But Daniel pointed me out that it would add a lot of complexity on
> > > management tool side, as it would need to know how to interpret these
> > > key/value pairs. I think his argument is very valid.
> > >
> > > So maybe the best way would be the version string, letting the
> > > application (OVS-DPDK/VPP/...) specify which version it is
> > > compatible with.
> > > For the downsides, as soon as a new feature is supported in vhost-user
> > > application, the new version will not be advertised as compatible with
> > > the previous one, even if the user disables the feature in Qemu (as
> > > pointed out by Yuanhan).
> >
> > We need two distinct capabilities in order to make this work properly.
> >
> > First, libvirt needs to be able to query the list of (one or more)
> > supported versions strings for a given host.
>
> Shouldn't be the role of OpenStack/Neutron? IIUC, libvirt knows nothing
> about OVS.
If libvirt doesn't know about it, then libvirt can't do any migration
checks upfront. Nova will have todo a check against supported version
strings before triggering migrate in libvirt. That's probably fine
from libvirt POV.
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :|
^ permalink raw reply
* Re: [PATCH 00/25] net/qede: update qede pmd to 2.0.0.1
From: Ferruh Yigit @ 2016-12-09 16:53 UTC (permalink / raw)
To: Rasesh Mody, dev; +Cc: Dept-EngDPDKDev
In-Reply-To: <1480756289-11835-1-git-send-email-Rasesh.Mody@cavium.com>
On 12/3/2016 9:11 AM, Rasesh Mody wrote:
> Hi,
>
> This patch set consists of enhancements, new 8.14.x.x firmware support
> and semantic changes. It update the QEDE PMD version to 2.0.0.1.
>
> Please include in DPDK 17.02 release.
Hi Rasesh,
This patchset seems depends to both [1] and [2], can you confirm?
[1] http://dpdk.org/ml/archives/dev/2016-December/051260.html
[2] http://dpdk.org/ml/archives/dev/2016-December/051253.html
Thanks,
ferruh
>
> Thanks!
> Rasesh
>
<...>
^ permalink raw reply
* Re: [PATCH v1 0/4] app: make python apps python2/3 compliant
From: Mcnamara, John @ 2016-12-09 17:00 UTC (permalink / raw)
To: Neil Horman; +Cc: dev@dpdk.org, mkletzan@redhat.com
In-Reply-To: <20161209152836.GA23061@hmsreliant.think-freely.org>
> -----Original Message-----
> From: Neil Horman [mailto:nhorman@tuxdriver.com]
> Sent: Friday, December 9, 2016 3:29 PM
> To: Mcnamara, John <john.mcnamara@intel.com>
> Cc: dev@dpdk.org; mkletzan@redhat.com
> Subject: Re: [dpdk-dev] [PATCH v1 0/4] app: make python apps python2/3
> compliant
>
> On Thu, Dec 08, 2016 at 03:51:01PM +0000, John McNamara wrote:
> > These patches refactor the DPDK Python applications to make them
> > Python 2/3 compatible.
> >
> > In order to do this the patchset starts by making the apps PEP8
> > compliant in accordance with the DPDK Coding guidelines:
> >
> >
> > http://dpdk.org/doc/guides/contributing/coding_style.html#python-code
> >
> > Implementing PEP8 and Python 2/3 compliance means that we can check
> > all future Python patches for consistency. Python 2/3 support also
> > makes downstream packaging easier as more distros move to Python 3 as
> the system python.
> >
> > See the previous discussion about Python2/3 compatibilty here:
> >
> > http://dpdk.org/ml/archives/dev/2016-December/051683.html
> >
> > I've tested that the apps compile with python 2 and 3 and I've tested
> > some of the apps for consistent output but it needs additional testing.
> >
> > John McNamara (4):
> > app: make python apps pep8 compliant
> > app: make python apps python2/3 compliant
> > app: give python apps a consistent shebang line
> > doc: add required python versions to coding guidelines
> >
> > app/cmdline_test/cmdline_test.py | 87 ++-
> > app/cmdline_test/cmdline_test_data.py | 403 +++++-----
> > app/test/autotest.py | 46 +-
> > app/test/autotest_data.py | 831 +++++++++++---
> -------
> > app/test/autotest_runner.py | 740 +++++++++-----
> ----
> > app/test/autotest_test_funcs.py | 481 ++++++------
> > doc/guides/conf.py | 11 +-
> > doc/guides/contributing/coding_style.rst | 3 +-
> > examples/ip_pipeline/config/diagram-generator.py | 13 +-
> > .../ip_pipeline/config/pipeline-to-core-mapping.py | 11 +-
> > tools/cpu_layout.py | 79 +-
> > tools/dpdk-devbind.py | 26 +-
> > tools/dpdk-pmdinfo.py | 73 +-
> > 13 files changed, 1410 insertions(+), 1394 deletions(-)
> >
> > --
> > 2.7.4
> >
> I think the changelog is deceptive. It claims to make all the utilities
> python2 and 3 compliant. But compliance with python3 is more than just
> stylistic formatting. After this series several of these apps continue to
> fail under python3. dpdk-pmdinfo as an example:
>
> [nhorman@hmsreliant dpdk]$ ./tools/dpdk-pmdinfo.py ./build/app/testacl
> Traceback (most recent call last):
> File "./tools/dpdk-pmdinfo.py", line 607, in <module>
> main()
> File "./tools/dpdk-pmdinfo.py", line 596, in main
> readelf.process_dt_needed_entries()
> File "./tools/dpdk-pmdinfo.py", line 437, in process_dt_needed_entries
> rc = tag.needed.find("librte_pmd")
> TypeError: a bytes-like object is required, not 'str'
>
>
> I'm not saying its a bad patchset, but the changelog should reflect that
> the change is purely stylistic, not functional.
>
Hi Neil,
Mea cupla. In my defense I did say in the cover letter that I'd tested that the apps compiled but that they needed extra testing. I did functionally test some of the apps that I was more familiar with, but not all of them. In particular the test apps need functional testing.
However, the changes need to be functional rather than just cosmetic so I'll look into fixing pmdinfo with Python 3, unless you'd prefer to do that ;-). Since pmdinfo is dealing with binary data it may be tricky. That is often one of the real challenges of porting Python 2 code to Python 3. Hopefully elftools is compatible. Anyway I'll look into it.
And just to be clear, I don't think this patchset should be merged until all of the apps have been functionally tested. I'll put something in the final patchset to indicate that the modified apps have been tested.
John
^ permalink raw reply
* Re: [PATCH v1 0/4] app: make python apps python2/3 compliant
From: Neil Horman @ 2016-12-09 17:06 UTC (permalink / raw)
To: Mcnamara, John; +Cc: dev@dpdk.org, mkletzan@redhat.com
In-Reply-To: <B27915DBBA3421428155699D51E4CFE202671EE0@IRSMSX103.ger.corp.intel.com>
On Fri, Dec 09, 2016 at 05:00:19PM +0000, Mcnamara, John wrote:
>
>
> > -----Original Message-----
> > From: Neil Horman [mailto:nhorman@tuxdriver.com]
> > Sent: Friday, December 9, 2016 3:29 PM
> > To: Mcnamara, John <john.mcnamara@intel.com>
> > Cc: dev@dpdk.org; mkletzan@redhat.com
> > Subject: Re: [dpdk-dev] [PATCH v1 0/4] app: make python apps python2/3
> > compliant
> >
> > On Thu, Dec 08, 2016 at 03:51:01PM +0000, John McNamara wrote:
> > > These patches refactor the DPDK Python applications to make them
> > > Python 2/3 compatible.
> > >
> > > In order to do this the patchset starts by making the apps PEP8
> > > compliant in accordance with the DPDK Coding guidelines:
> > >
> > >
> > > http://dpdk.org/doc/guides/contributing/coding_style.html#python-code
> > >
> > > Implementing PEP8 and Python 2/3 compliance means that we can check
> > > all future Python patches for consistency. Python 2/3 support also
> > > makes downstream packaging easier as more distros move to Python 3 as
> > the system python.
> > >
> > > See the previous discussion about Python2/3 compatibilty here:
> > >
> > > http://dpdk.org/ml/archives/dev/2016-December/051683.html
> > >
> > > I've tested that the apps compile with python 2 and 3 and I've tested
> > > some of the apps for consistent output but it needs additional testing.
> > >
> > > John McNamara (4):
> > > app: make python apps pep8 compliant
> > > app: make python apps python2/3 compliant
> > > app: give python apps a consistent shebang line
> > > doc: add required python versions to coding guidelines
> > >
> > > app/cmdline_test/cmdline_test.py | 87 ++-
> > > app/cmdline_test/cmdline_test_data.py | 403 +++++-----
> > > app/test/autotest.py | 46 +-
> > > app/test/autotest_data.py | 831 +++++++++++---
> > -------
> > > app/test/autotest_runner.py | 740 +++++++++-----
> > ----
> > > app/test/autotest_test_funcs.py | 481 ++++++------
> > > doc/guides/conf.py | 11 +-
> > > doc/guides/contributing/coding_style.rst | 3 +-
> > > examples/ip_pipeline/config/diagram-generator.py | 13 +-
> > > .../ip_pipeline/config/pipeline-to-core-mapping.py | 11 +-
> > > tools/cpu_layout.py | 79 +-
> > > tools/dpdk-devbind.py | 26 +-
> > > tools/dpdk-pmdinfo.py | 73 +-
> > > 13 files changed, 1410 insertions(+), 1394 deletions(-)
> > >
> > > --
> > > 2.7.4
> > >
> > I think the changelog is deceptive. It claims to make all the utilities
> > python2 and 3 compliant. But compliance with python3 is more than just
> > stylistic formatting. After this series several of these apps continue to
> > fail under python3. dpdk-pmdinfo as an example:
> >
> > [nhorman@hmsreliant dpdk]$ ./tools/dpdk-pmdinfo.py ./build/app/testacl
> > Traceback (most recent call last):
> > File "./tools/dpdk-pmdinfo.py", line 607, in <module>
> > main()
> > File "./tools/dpdk-pmdinfo.py", line 596, in main
> > readelf.process_dt_needed_entries()
> > File "./tools/dpdk-pmdinfo.py", line 437, in process_dt_needed_entries
> > rc = tag.needed.find("librte_pmd")
> > TypeError: a bytes-like object is required, not 'str'
> >
> >
> > I'm not saying its a bad patchset, but the changelog should reflect that
> > the change is purely stylistic, not functional.
> >
>
> Hi Neil,
>
> Mea cupla. In my defense I did say in the cover letter that I'd tested that the apps compiled but that they needed extra testing. I did functionally test some of the apps that I was more familiar with, but not all of them. In particular the test apps need functional testing.
>
> However, the changes need to be functional rather than just cosmetic so I'll look into fixing pmdinfo with Python 3, unless you'd prefer to do that ;-). Since pmdinfo is dealing with binary data it may be tricky. That is often one of the real challenges of porting Python 2 code to Python 3. Hopefully elftools is compatible. Anyway I'll look into it.
>
> And just to be clear, I don't think this patchset should be merged until all of the apps have been functionally tested. I'll put something in the final patchset to indicate that the modified apps have been tested.
>
I completely agree that the utilities should be functionally compatible with
python 3, but in regards to this patch set, all I'm really asking for is that
the changelog reflect that its just making stylistic changes to comply with pep8
(i.e. not fixing python 2/3 compatibility issues). The latter can be handled in
subsequent patches piecemeal.
Neil
> John
>
>
>
>
>
>
>
^ permalink raw reply
* Re: [PATCH v12 1/6] ethdev: add Tx preparation
From: Kulasek, TomaszX @ 2016-12-09 17:19 UTC (permalink / raw)
To: Olivier Matz, Ananyev, Konstantin; +Cc: Thomas Monjalon, dev@dpdk.org
In-Reply-To: <20161208182417.32ec3933@platinum>
Hi Oliver,
My 5 cents below:
> -----Original Message-----
> From: Olivier Matz [mailto:olivier.matz@6wind.com]
> Sent: Thursday, December 8, 2016 18:24
> To: Ananyev, Konstantin <konstantin.ananyev@intel.com>
> Cc: Thomas Monjalon <thomas.monjalon@6wind.com>; Kulasek, TomaszX
> <tomaszx.kulasek@intel.com>; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v12 1/6] ethdev: add Tx preparation
>
> Hi Konstantin,
>
> On Fri, 2 Dec 2016 16:17:51 +0000, "Ananyev, Konstantin"
> <konstantin.ananyev@intel.com> wrote:
> > Hi Olivier,
> >
> > > -----Original Message-----
> > > From: Olivier Matz [mailto:olivier.matz@6wind.com]
> > > Sent: Friday, December 2, 2016 8:24 AM
> > > To: Ananyev, Konstantin <konstantin.ananyev@intel.com>
> > > Cc: Thomas Monjalon <thomas.monjalon@6wind.com>; Kulasek, TomaszX
> > > <tomaszx.kulasek@intel.com>; dev@dpdk.org Subject: Re: [dpdk-dev]
> > > [PATCH v12 1/6] ethdev: add Tx preparation
> > >
> > > Hi Konstantin,
> > >
> > > On Fri, 2 Dec 2016 01:06:30 +0000, "Ananyev, Konstantin"
> > > <konstantin.ananyev@intel.com> wrote:
> > > > >
> > > > > 2016-11-23 18:36, Tomasz Kulasek:
> > > > > > +/**
> > > > > > + * Process a burst of output packets on a transmit queue of
> > > > > > an Ethernet device.
> > > > > > + *
> > > > > > + * The rte_eth_tx_prepare() function is invoked to prepare
> > > > > > output packets to be
> > > > > > + * transmitted on the output queue *queue_id* of the Ethernet
> > > > > > device designated
> > > > > > + * by its *port_id*.
> > > > > > + * The *nb_pkts* parameter is the number of packets to be
> > > > > > prepared which are
> > > > > > + * supplied in the *tx_pkts* array of *rte_mbuf* structures,
> > > > > > each of them
> > > > > > + * allocated from a pool created with
> > > > > > rte_pktmbuf_pool_create().
> > > > > > + * For each packet to send, the rte_eth_tx_prepare() function
> > > > > > performs
> > > > > > + * the following operations:
> > > > > > + *
> > > > > > + * - Check if packet meets devices requirements for tx
> > > > > > offloads.
> > > > > > + *
> > > > > > + * - Check limitations about number of segments.
> > > > > > + *
> > > > > > + * - Check additional requirements when debug is enabled.
> > > > > > + *
> > > > > > + * - Update and/or reset required checksums when tx offload
> > > > > > is set for packet.
> > > > > > + *
> > > > > > + * Since this function can modify packet data, provided mbufs
> > > > > > must be safely
> > > > > > + * writable (e.g. modified data cannot be in shared
> > > > > > segment).
> > > > >
> > > > > I think we will have to remove this limitation in next releases.
> > > > > As we don't know how it could affect the API, I suggest to
> > > > > declare this API EXPERIMENTAL.
> > > >
> > > > While I don't really mind to mart it as experimental, I don't
> > > > really understand the reasoning: Why " this function can modify
> > > > packet data, provided mbufs must be safely writable" suddenly
> > > > becomes a problem? That seems like and obvious limitation to me
> > > > and let say tx_burst() has the same one. Second, I don't see how
> > > > you are going to remove it without introducing a heavy performance
> > > > impact. Konstantin
> > >
> > > About tx_burst(), I don't think we should force the user to provide
> > > a writable mbuf. There are many use cases where passing a clone
> > > already works as of today and it avoids duplicating the mbuf data.
> > > For instance: traffic generator, multicast, bridging/tap, etc...
> > >
> > > Moreover, this requirement would be inconsistent with the model you
> > > are proposing in case of pipeline:
> > > - tx_prepare() on core X, may update the data
> > > - tx_burst() on core Y, should not touch the data to avoid cache
> > > misses
> >
> > Probably I wasn't very clear in my previous mail.
> > I am not saying that we should force the user to pass a writable mbuf.
> > What I am saying that for tx_burst() current expectation is that after
> > mbuf is handled to tx_burst() user shouldn't try to modify its buffer
> > contents till TX engine is done with the buffer (mbuf_free() is called
> > by TX func for it). For tx_prep(), I think, it is the same though
> > restrictions are a bit more strict: user should not try to read/write
> > to the mbuf while tx_prep() is not finished with it. What puzzles me
> > is that why that should be the reason to mark tx_prep() as
> > experimental. Konstantin
>
> To be sure we're on the same page, let me reword:
>
> - mbufs passed to tx_prepare() by the application must have their
> headers (l2_len + l3_len + l4_len) writable because the phdr checksum
> can be replaced. It could be precised in the api comment.
>
> - mbufs passed to tx_burst() must not be modified by the driver/hw, nor
> by the application.
>
>
> About the API itself, I have one more question. I know you've already
> discussed this a bit with Adrien, I don't want to spawn a new big thread
> from here ;)
>
> The API provides tx_prepare() to check the packets have the proper format,
> and possibly modify them (ex: csum offload / tso) to match hw
> requirements. So it does both checks (number of segments) and fixes
> (csum/tso). What determines things that should be checked and things that
> should be fixed?
>
1) Performance -- we may assume that packets are created with the common rules (e.g. doesn't tries to count IP checksum for IPv6 packet, sets all required fields, etc.). For now, additional checks are done only in DEBUG mode.
2) Uncommon requirements, such a number of segments for TSO/non-TSO, where invalid values can cause unexpected results (or even hang device on burst), so it is critical (at least for ixgbe and i40e) and must be checked.
3) Checksum field must be initialized in a hardware specific way to count it properly.
4) If packet is invalid its content isn't modified nor restored.
> The application gets few information from tx_prepare() about what should
> be done to make the packet accepted by the hw, and the actions will
> probably be different depending on hardware. So could we imagine that in
> the future the function also tries to fix the packet? I've seen your
> comment saying that it has to be an application decision, so what about
> having a parameter saying "fix the packet" or "don't fix it"?
>
The main question here is how invasive in packet data tx_prepare should be.
If I understand you correctly, you're talking about the situation when tx_prepare will try to restore packet internally, e.g. linearize data for i40e to meet number of segments requirements, split mbufs, when are too large, maybe someone will wanted to have full software checksum computation fallback for devices which doesn't support it, and so on? And then this parameter will indicate "do the required work for me", or "just check, initialize what should be initialized, if fails, let me decide"?
Implemented model is quite simple and clear:
1) Validate uncommon requirements which may cause a problem and let application to deal with it.
2) If packet is valid, initialize required fields according to the hardware requirements.
In fact, it doesn't fix anything for now, but initializes checksums, and the main reason why it is done here, is the fact that it cannot be done in a trivial way in the application itself.
IMHO, we should to keep this API as simple as it possible and not let it grow in unexpected way (also for performance reason).
> About rte_eth_desc_lim->nb_seg_max and
> rte_eth_desc_lim->nb_mtu_seg_max, I'm still quite reserved, especially for
> the 2nd one, because I don't see how it can be used by the application.
> Well, it does not hurt to have them, but for me it looks a bit useless.
>
* "nb_seg_max": Maximum number of segments per whole packet.
* "nb_mtu_seg_max": Maximum number of segments per one MTU.
Application can use provided values in a fallowed way:
* For non-TSO packet, a single transmit packet may span up to "nb_mtu_seg_max" buffers.
* For TSO packet the total number of data descriptors is "nb_seg_max", and each segment within the TSO may span up to "nb_mtu_seg_max".
> Last thing, I think this API should become the default in the future.
> For instance, it would prevent the application to calculate a phdr csum
> that will not be used by the hw. Not calling tx_prepare() would require
> the user/application to exactly knows the underlying hw and the kind of
> packet that are generated. So for me it means we'll need to also update
> other examples (other testpmd engines, l2fwd, ...). Do you agree?
>
Most of sample applications doesn't use TX offloads at all and doesn't count checksums. So the question is "should tx_prepare be used even if not required?"
>
> Regards,
> Olivier
>
Tomasz
^ permalink raw reply
* [PATCH v2 0/9] net/ixgbe: move set VF functions.
From: Bernard Iremonger @ 2016-12-09 17:25 UTC (permalink / raw)
To: thomas.monjalon, dev; +Cc: Bernard Iremonger
In-Reply-To: <1481282878-26176-1-git-send-email-bernard.iremonger@intel.com>
This patchset implements the following deprecation notice:
[PATCH v1] doc: announce API and ABI change for librte_ether
Changes in V2:
Update testpmd set vf commands help messages.
Updated ethtool to use the ixgbe public API's.
Removed the ixgbe_set_pool_* and ixgbe_set_vf_rate_limit functions.
Removed the rte_eth_dev_set_vf_* API's
Removed the deprecation notice.
Changes in V1:
The following functions from eth_dev_ops have been moved to the ixgbe PMD
and renamed:
ixgbe_set_pool_rx_mode
ixgbe_set_pool_rx
ixgbe_set_pool_tx
ixgbe_set_pool_vlan_filter
ixgbe_set_vf_rate_limit
Renamed the functions to the following:
rte_pmd_ixgbe_set_vf_rxmode
rte_pmd_ixgbe_set_vf_rx
rte_pmd_ixgbe_set_vf_tx
rte_pmd_ixgbe_set_vf_vlan_filter
rte_pmd_ixgbe_set_vf_rate_limit
Testpmd has been modified to use the following functions:
rte_pmd_ixgbe_set_vf_rxmode
rte_pmd_ixgbe_set_vf_rate_limit
New testpmd commands have been added to test the following functions:
rte_pmd_ixgbe_set_vf_rx
rte_pmd_ixgbe_set_vf_tx
rte_pmd_ixgbe_set_vf_vlan_filter
The testpmd user guide has been updated for the new commands.
Bernard Iremonger (9):
net/ixgbe: move set VF functions from the ethdev
app/testpmd: use ixgbe public functions
app/testpmd: add command for set VF VLAN filter
app/testpmd: add command for set VF receive
app/testpmd: add command for set VF transmit
examples/ethtool: use ixgbe public function
net/ixgbe: remove static set VF functions
librte_ether: remove the set VF API's
doc: remove deprecation notice
app/test-pmd/cmdline.c | 270 +++++++++++++++-
app/test-pmd/config.c | 31 +-
doc/guides/rel_notes/deprecation.rst | 13 -
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 21 ++
drivers/net/ixgbe/ixgbe_ethdev.c | 459 ++++++++++++++++------------
drivers/net/ixgbe/rte_pmd_ixgbe.h | 104 +++++++
drivers/net/ixgbe/rte_pmd_ixgbe_version.map | 10 +
examples/ethtool/lib/rte_ethtool.c | 5 +-
lib/librte_ether/rte_ethdev.c | 129 --------
lib/librte_ether/rte_ethdev.h | 33 --
10 files changed, 683 insertions(+), 392 deletions(-)
--
2.10.1
^ permalink raw reply
* [PATCH v2 1/9] net/ixgbe: move set VF functions from the ethdev
From: Bernard Iremonger @ 2016-12-09 17:25 UTC (permalink / raw)
To: thomas.monjalon, dev; +Cc: Bernard Iremonger
In-Reply-To: <1481282878-26176-1-git-send-email-bernard.iremonger@intel.com>
Move the following functions from eth_dev_ops to the ixgbe PMD and rename:
ixgbe_set_pool_rx_mode
ixgbe_set_pool_rx
ixgbe_set_pool_tx
ixgbe_set_pool_vlan_filter
ixgbe_set_vf_rate_limit
Rename the functions to the following:
rte_pmd_ixgbe_set_vf_rxmode
rte_pmd_ixgbe_set_vf_rx
rte_pmd_ixgbe_set_vf_tx
rte_pmd_ixgbe_set_vf_vlan_filter
rte_pmd_ixgbe_set_vf_rate_limit
Use public function internally
Signed-off-by: Bernard Iremonger <bernard.iremonger@intel.com>
---
drivers/net/ixgbe/ixgbe_ethdev.c | 266 +++++++++++++++++++++++++++-
drivers/net/ixgbe/rte_pmd_ixgbe.h | 104 +++++++++++
drivers/net/ixgbe/rte_pmd_ixgbe_version.map | 10 ++
3 files changed, 379 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index edc9b22..37b82a4 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -2294,7 +2294,8 @@ ixgbe_dev_start(struct rte_eth_dev *dev)
for (vf = 0; vf < dev->pci_dev->max_vfs; vf++)
for (idx = 0; idx < IXGBE_MAX_QUEUE_NUM_PER_VF; idx++)
if (vfinfo[vf].tx_rate[idx] != 0)
- ixgbe_set_vf_rate_limit(dev, vf,
+ rte_pmd_ixgbe_set_vf_rate_limit(
+ dev->data->port_id, vf,
vfinfo[vf].tx_rate[idx],
1 << idx);
}
@@ -4883,6 +4884,269 @@ rte_pmd_ixgbe_set_vf_vlan_stripq(uint8_t port, uint16_t vf, uint8_t on)
return 0;
}
+int
+rte_pmd_ixgbe_set_vf_rxmode(uint8_t port, uint16_t vf, uint16_t rx_mask, uint8_t on)
+{
+ int val = 0;
+ struct rte_eth_dev *dev;
+ struct rte_eth_dev_info dev_info;
+ struct ixgbe_hw *hw;
+ uint32_t vmolr;
+
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(port, -ENODEV);
+
+ dev = &rte_eth_devices[port];
+ rte_eth_dev_info_get(port, &dev_info);
+
+ if (strstr(dev_info.driver_name, "ixgbe_vf"))
+ return -ENOTSUP;
+
+ if (vf >= dev_info.max_vfs)
+ return -EINVAL;
+
+ if (on > 1)
+ return -EINVAL;
+
+ hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+ vmolr = IXGBE_READ_REG(hw, IXGBE_VMOLR(vf));
+
+ if (hw->mac.type == ixgbe_mac_82598EB) {
+ PMD_INIT_LOG(ERR, "setting VF receive mode set should be done"
+ " on 82599 hardware and newer");
+ return -ENOTSUP;
+ }
+ if (ixgbe_vmdq_mode_check(hw) < 0)
+ return -ENOTSUP;
+
+ val = ixgbe_convert_vm_rx_mask_to_val(rx_mask, val);
+
+ if (on)
+ vmolr |= val;
+ else
+ vmolr &= ~val;
+
+ IXGBE_WRITE_REG(hw, IXGBE_VMOLR(vf), vmolr);
+
+ return 0;
+}
+
+int
+rte_pmd_ixgbe_set_vf_rx(uint8_t port, uint16_t vf, uint8_t on)
+{
+ struct rte_eth_dev *dev;
+ struct rte_eth_dev_info dev_info;
+ uint32_t reg, addr;
+ uint32_t val;
+ const uint8_t bit1 = 0x1;
+ struct ixgbe_hw *hw;
+
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(port, -ENODEV);
+
+ dev = &rte_eth_devices[port];
+ rte_eth_dev_info_get(port, &dev_info);
+
+ if (strstr(dev_info.driver_name, "ixgbe_vf"))
+ return -ENOTSUP;
+
+ if (vf >= dev_info.max_vfs)
+ return -EINVAL;
+
+ if (on > 1)
+ return -EINVAL;
+
+ hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+
+ if (ixgbe_vmdq_mode_check(hw) < 0)
+ return -ENOTSUP;
+
+ /* for vf >= 32, set bit in PFVFRE[1], otherwise PFVFRE[0] */
+ if (vf >= 32) {
+ addr = IXGBE_VFRE(1);
+ val = bit1 << (vf - 32);
+ } else {
+ addr = IXGBE_VFRE(0);
+ val = bit1 << vf;
+ }
+
+ reg = IXGBE_READ_REG(hw, addr);
+
+ if (on)
+ reg |= val;
+ else
+ reg &= ~val;
+
+ IXGBE_WRITE_REG(hw, addr, reg);
+
+ return 0;
+}
+
+int
+rte_pmd_ixgbe_set_vf_tx(uint8_t port, uint16_t vf, uint8_t on)
+{
+ struct rte_eth_dev *dev;
+ struct rte_eth_dev_info dev_info;
+ uint32_t reg, addr;
+ uint32_t val;
+ const uint8_t bit1 = 0x1;
+
+ struct ixgbe_hw *hw;
+
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(port, -ENODEV);
+
+ dev = &rte_eth_devices[port];
+ rte_eth_dev_info_get(port, &dev_info);
+
+ if (strstr(dev_info.driver_name, "ixgbe_vf"))
+ return -ENOTSUP;
+
+ if (vf >= dev_info.max_vfs)
+ return -EINVAL;
+
+ if (on > 1)
+ return -EINVAL;
+
+ hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+ if (ixgbe_vmdq_mode_check(hw) < 0)
+ return -ENOTSUP;
+
+ /* for vf >= 32, set bit in PFVFTE[1], otherwise PFVFTE[0] */
+ if (vf >= 32) {
+ addr = IXGBE_VFTE(1);
+ val = bit1 << (vf - 32);
+ } else {
+ addr = IXGBE_VFTE(0);
+ val = bit1 << vf;
+ }
+
+ reg = IXGBE_READ_REG(hw, addr);
+
+ if (on)
+ reg |= val;
+ else
+ reg &= ~val;
+
+ IXGBE_WRITE_REG(hw, addr, reg);
+
+ return 0;
+}
+
+int
+rte_pmd_ixgbe_set_vf_vlan_filter(uint8_t port, uint16_t vlan,
+ uint64_t vf_mask, uint8_t vlan_on)
+{
+ struct rte_eth_dev *dev;
+ struct rte_eth_dev_info dev_info;
+ int ret = 0;
+ uint16_t vf_idx;
+ struct ixgbe_hw *hw;
+
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(port, -ENODEV);
+
+ dev = &rte_eth_devices[port];
+ rte_eth_dev_info_get(port, &dev_info);
+
+ if (strstr(dev_info.driver_name, "ixgbe_vf"))
+ return -ENOTSUP;
+
+ if ((vlan > ETHER_MAX_VLAN_ID) || (vf_mask == 0))
+ return -EINVAL;
+
+ hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+ if (ixgbe_vmdq_mode_check(hw) < 0)
+ return -ENOTSUP;
+
+ for (vf_idx = 0; vf_idx < 64; vf_idx++) {
+ if (vf_mask & ((uint64_t)(1ULL << vf_idx))) {
+ ret = hw->mac.ops.set_vfta(hw, vlan, vf_idx,
+ vlan_on, false);
+ if (ret < 0)
+ return ret;
+ }
+ }
+
+ return ret;
+}
+
+int rte_pmd_ixgbe_set_vf_rate_limit(uint8_t port, uint16_t vf,
+ uint16_t tx_rate, uint64_t q_msk)
+{
+ struct rte_eth_dev *dev;
+ struct rte_eth_dev_info dev_info;
+ struct ixgbe_hw *hw;
+ struct ixgbe_vf_info *vfinfo;
+ struct rte_eth_link link;
+ uint8_t nb_q_per_pool;
+ uint32_t queue_stride;
+ uint32_t queue_idx, idx = 0, vf_idx;
+ uint32_t queue_end;
+ uint16_t total_rate = 0;
+
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(port, -ENODEV);
+
+ dev = &rte_eth_devices[port];
+ rte_eth_dev_info_get(port, &dev_info);
+ rte_eth_link_get_nowait(port, &link);
+
+ if (strstr(dev_info.driver_name, "ixgbe_vf"))
+ return -ENOTSUP;
+
+ if (vf >= dev_info.max_vfs)
+ return -EINVAL;
+
+ if (tx_rate > link.link_speed)
+ return -EINVAL;
+
+ if (q_msk == 0)
+ return 0;
+
+ hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+ vfinfo = *(IXGBE_DEV_PRIVATE_TO_P_VFDATA(dev->data->dev_private));
+ nb_q_per_pool = RTE_ETH_DEV_SRIOV(dev).nb_q_per_pool;
+ queue_stride = IXGBE_MAX_RX_QUEUE_NUM / RTE_ETH_DEV_SRIOV(dev).active;
+ queue_idx = vf * queue_stride;
+ queue_end = queue_idx + nb_q_per_pool - 1;
+ if (queue_end >= hw->mac.max_tx_queues)
+ return -EINVAL;
+
+ if (vfinfo) {
+ for (vf_idx = 0; vf_idx < dev->pci_dev->max_vfs; vf_idx++) {
+ if (vf_idx == vf)
+ continue;
+ for (idx = 0; idx < RTE_DIM(vfinfo[vf_idx].tx_rate);
+ idx++)
+ total_rate += vfinfo[vf_idx].tx_rate[idx];
+ }
+ } else {
+ return -EINVAL;
+ }
+
+ /* Store tx_rate for this vf. */
+ for (idx = 0; idx < nb_q_per_pool; idx++) {
+ if (((uint64_t)0x1 << idx) & q_msk) {
+ if (vfinfo[vf].tx_rate[idx] != tx_rate)
+ vfinfo[vf].tx_rate[idx] = tx_rate;
+ total_rate += tx_rate;
+ }
+ }
+
+ if (total_rate > dev->data->dev_link.link_speed) {
+ /* Reset stored TX rate of the VF if it causes exceed
+ * link speed.
+ */
+ memset(vfinfo[vf].tx_rate, 0, sizeof(vfinfo[vf].tx_rate));
+ return -EINVAL;
+ }
+
+ /* Set RTTBCNRC of each queue/pool for vf X */
+ for (; queue_idx <= queue_end; queue_idx++) {
+ if (0x1 & q_msk)
+ ixgbe_set_queue_rate_limit(dev, queue_idx, tx_rate);
+ q_msk = q_msk >> 1;
+ }
+
+ return 0;
+}
+
#define IXGBE_MRCTL_VPME 0x01 /* Virtual Pool Mirroring. */
#define IXGBE_MRCTL_UPME 0x02 /* Uplink Port Mirroring. */
#define IXGBE_MRCTL_DPME 0x04 /* Downlink Port Mirroring. */
diff --git a/drivers/net/ixgbe/rte_pmd_ixgbe.h b/drivers/net/ixgbe/rte_pmd_ixgbe.h
index c2fb826..4eb0c9a 100644
--- a/drivers/net/ixgbe/rte_pmd_ixgbe.h
+++ b/drivers/net/ixgbe/rte_pmd_ixgbe.h
@@ -183,6 +183,110 @@ int
rte_pmd_ixgbe_set_vf_vlan_stripq(uint8_t port, uint16_t vf, uint8_t on);
/**
+* Set RX L2 Filtering mode of a VF of an Ethernet device.
+*
+* @param port
+* The port identifier of the Ethernet device.
+* @param vf
+* VF id.
+* @param rx_mode
+* The RX mode mask, which is one or more of accepting Untagged Packets,
+* packets that match the PFUTA table, Broadcast and Multicast Promiscuous.
+* ETH_VMDQ_ACCEPT_UNTAG,ETH_VMDQ_ACCEPT_HASH_UC,
+* ETH_VMDQ_ACCEPT_BROADCAST and ETH_VMDQ_ACCEPT_MULTICAST will be used
+* in rx_mode.
+* @param on
+* 1 - Enable a VF RX mode.
+* 0 - Disable a VF RX mode.
+* @return
+* - (0) if successful.
+* - (-ENOTSUP) if hardware doesn't support.
+* - (-ENODEV) if *port_id* invalid.
+* - (-EINVAL) if bad parameter.
+*/
+int
+rte_pmd_ixgbe_set_vf_rxmode(uint8_t port, uint16_t vf, uint16_t rx_mask, uint8_t on);
+
+/**
+* Enable or disable a VF traffic receive of an Ethernet device.
+*
+* @param port
+* The port identifier of the Ethernet device.
+* @param vf
+* VF id.
+* @param on
+* 1 - Enable a VF traffic receive.
+* 0 - Disable a VF traffic receive.
+* @return
+* - (0) if successful.
+* - (-ENOTSUP) if hardware doesn't support.
+* - (-ENODEV) if *port_id* invalid.
+* - (-EINVAL) if bad parameter.
+*/
+int
+rte_pmd_ixgbe_set_vf_rx(uint8_t port, uint16_t vf, uint8_t on);
+
+/**
+* Enable or disable a VF traffic transmit of the Ethernet device.
+*
+* @param port
+* The port identifier of the Ethernet device.
+* @param vf
+* VF id.
+* @param on
+* 1 - Enable a VF traffic transmit.
+* 0 - Disable a VF traffic transmit.
+* @return
+* - (0) if successful.
+* - (-ENODEV) if *port_id* invalid.
+* - (-ENOTSUP) if hardware doesn't support.
+* - (-EINVAL) if bad parameter.
+*/
+int
+rte_pmd_ixgbe_set_vf_tx(uint8_t port, uint16_t vf, uint8_t on);
+
+/**
+* Enable/Disable hardware VF VLAN filtering by an Ethernet device of
+* received VLAN packets tagged with a given VLAN Tag Identifier.
+*
+* @param port id
+* The port identifier of the Ethernet device.
+* @param vlan_id
+* The VLAN Tag Identifier whose filtering must be enabled or disabled.
+* @param vf_mask
+* Bitmap listing which VFs participate in the VLAN filtering.
+* @param vlan_on
+* 1 - Enable VFs VLAN filtering.
+* 0 - Disable VFs VLAN filtering.
+* @return
+* - (0) if successful.
+* - (-ENOTSUP) if hardware doesn't support.
+* - (-ENODEV) if *port_id* invalid.
+* - (-EINVAL) if bad parameter.
+*/
+int
+rte_pmd_ixgbe_set_vf_vlan_filter(uint8_t port, uint16_t vlan, uint64_t vf_mask, uint8_t vlan_on);
+
+/**
+ * Set the rate limitation for a vf on an Ethernet device.
+ *
+ * @param port_id
+ * The port identifier of the Ethernet device.
+ * @param vf
+ * VF id.
+ * @param tx_rate
+ * The tx rate allocated from the total link speed for this VF id.
+ * @param q_msk
+ * The queue mask which need to set the rate.
+ * @return
+ * - (0) if successful.
+ * - (-ENOTSUP) if hardware doesn't support this feature.
+ * - (-ENODEV) if *port_id* invalid.
+ * - (-EINVAL) if bad parameter.
+ */
+int rte_pmd_ixgbe_set_vf_rate_limit(uint8_t port, uint16_t vf, uint16_t tx_rate, uint64_t q_msk);
+
+/**
* Response sent back to ixgbe driver from user app after callback
*/
enum rte_pmd_ixgbe_mb_event_rsp {
diff --git a/drivers/net/ixgbe/rte_pmd_ixgbe_version.map b/drivers/net/ixgbe/rte_pmd_ixgbe_version.map
index 92434f3..5252bc2 100644
--- a/drivers/net/ixgbe/rte_pmd_ixgbe_version.map
+++ b/drivers/net/ixgbe/rte_pmd_ixgbe_version.map
@@ -15,3 +15,13 @@ DPDK_16.11 {
rte_pmd_ixgbe_set_vf_vlan_insert;
rte_pmd_ixgbe_set_vf_vlan_stripq;
} DPDK_2.0;
+
+DPDK_17.02 {
+ global:
+
+ rte_pmd_ixgbe_set_vf_rate_limit;
+ rte_pmd_ixgbe_set_vf_rx;
+ rte_pmd_ixgbe_set_vf_rxmode;
+ rte_pmd_ixgbe_set_vf_tx;
+ rte_pmd_ixgbe_set_vf_vlan_filter;
+} DPDK_16.11;
\ No newline at end of file
--
2.10.1
^ permalink raw reply related
* [PATCH v2 2/9] app/testpmd: use ixgbe public functions
From: Bernard Iremonger @ 2016-12-09 17:25 UTC (permalink / raw)
To: thomas.monjalon, dev; +Cc: Bernard Iremonger
In-Reply-To: <1481282878-26176-1-git-send-email-bernard.iremonger@intel.com>
Use the the following ixgbe public functions:
rte_pmd_ixgbe_set_vf_rate_limit
rte_pmd_ixgbe_set_vf_rx
rte_pmd_ixgbe_set_vf_rxmode
rte_pmd_ixgbe_set_vf_tx
rte_pmd_ixgbe_set_vf_vlan_filter
Signed-off-by: Bernard Iremonger <bernard.iremonger@intel.com>
---
app/test-pmd/cmdline.c | 2 +-
app/test-pmd/config.c | 31 +++++++++++--------------------
2 files changed, 12 insertions(+), 21 deletions(-)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index d03a592..12f799b 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -6708,7 +6708,7 @@ cmd_set_vf_rxmode_parsed(void *parsed_result,
rx_mode |= ETH_VMDQ_ACCEPT_MULTICAST;
}
- ret = rte_eth_dev_set_vf_rxmode(res->port_id,res->vf_id,rx_mode,(uint8_t)is_on);
+ ret = rte_pmd_ixgbe_set_vf_rxmode(res->port_id, res->vf_id, rx_mode, (uint8_t)is_on);
if (ret < 0)
printf("bad VF receive mode parameter, return code = %d \n",
ret);
diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index 8cf537d..ea129db 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -92,6 +92,9 @@
#include <rte_ethdev.h>
#include <rte_string_fns.h>
#include <rte_cycles.h>
+#ifdef RTE_LIBRTE_IXGBE_PMD
+#include <rte_pmd_ixgbe.h>
+#endif
#include "testpmd.h"
@@ -2332,16 +2335,16 @@ set_vf_traffic(portid_t port_id, uint8_t is_rx, uint16_t vf, uint8_t on)
if (port_id_is_invalid(port_id, ENABLED_WARN))
return;
if (is_rx)
- diag = rte_eth_dev_set_vf_rx(port_id,vf,on);
+ diag = rte_pmd_ixgbe_set_vf_rx(port_id, vf, on);
else
- diag = rte_eth_dev_set_vf_tx(port_id,vf,on);
+ diag = rte_pmd_ixgbe_set_vf_tx(port_id, vf, on);
if (diag == 0)
return;
if(is_rx)
- printf("rte_eth_dev_set_vf_rx for port_id=%d failed "
+ printf("rte_pmd_ixgbe_set_vf_rx for port_id=%d failed "
"diag=%d\n", port_id, diag);
else
- printf("rte_eth_dev_set_vf_tx for port_id=%d failed "
+ printf("rte_pmd_ixgbe_set_vf_tx for port_id=%d failed "
"diag=%d\n", port_id, diag);
}
@@ -2355,10 +2358,10 @@ set_vf_rx_vlan(portid_t port_id, uint16_t vlan_id, uint64_t vf_mask, uint8_t on)
return;
if (vlan_id_is_invalid(vlan_id))
return;
- diag = rte_eth_dev_set_vf_vlan_filter(port_id, vlan_id, vf_mask, on);
+ diag = rte_pmd_ixgbe_set_vf_vlan_filter(port_id, vlan_id, vf_mask, on);
if (diag == 0)
return;
- printf("rte_eth_dev_set_vf_vlan_filter for port_id=%d failed "
+ printf("rte_pmd_ixgbe_set_vf_vlan_filter for port_id=%d failed "
"diag=%d\n", port_id, diag);
}
@@ -2388,23 +2391,11 @@ int
set_vf_rate_limit(portid_t port_id, uint16_t vf, uint16_t rate, uint64_t q_msk)
{
int diag;
- struct rte_eth_link link;
-
- if (q_msk == 0)
- return 0;
- if (port_id_is_invalid(port_id, ENABLED_WARN))
- return 1;
- rte_eth_link_get_nowait(port_id, &link);
- if (rate > link.link_speed) {
- printf("Invalid rate value:%u bigger than link speed: %u\n",
- rate, link.link_speed);
- return 1;
- }
- diag = rte_eth_set_vf_rate_limit(port_id, vf, rate, q_msk);
+ diag = rte_pmd_ixgbe_set_vf_rate_limit(port_id, vf, rate, q_msk);
if (diag == 0)
return diag;
- printf("rte_eth_set_vf_rate_limit for port_id=%d failed diag=%d\n",
+ printf("rte_pmd_ixgbe_set_vf_rate_limit for port_id=%d failed diag=%d\n",
port_id, diag);
return diag;
}
--
2.10.1
^ permalink raw reply related
* [PATCH v2 3/9] app/testpmd: add command for set VF VLAN filter
From: Bernard Iremonger @ 2016-12-09 17:25 UTC (permalink / raw)
To: thomas.monjalon, dev; +Cc: Bernard Iremonger
In-Reply-To: <1481282878-26176-1-git-send-email-bernard.iremonger@intel.com>
Add the following command to testpmd:
set vf vlan filter <port_id> <vlan_id> <vf_mask> on|off
Add command to the testpmd user guide.
Signed-off-by: Bernard Iremonger <bernard.iremonger@intel.com>
---
app/test-pmd/cmdline.c | 98 +++++++++++++++++++++++++++++
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 7 +++
2 files changed, 105 insertions(+)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 12f799b..947c698 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -291,6 +291,9 @@ static void cmd_help_long_parsed(void *parsed_result,
"set vf vlan antispoof (port_id) (vf_id) (on|off)\n"
" Set VLAN antispoof for a VF from the PF.\n\n"
+
+ "set vf vlan filter (port_id) (vlan_id) (vf_mask) (on|off)\n"
+ " Set VLAN filter for a VF pool from the PF.\n\n"
#endif
"vlan set filter (on|off) (port_id)\n"
@@ -11139,6 +11142,100 @@ cmdline_parse_inst_t cmd_set_vf_vlan_insert = {
},
};
+
+/* vf vlan filter configuration */
+
+/* Common result structure for vf vlan filter */
+struct cmd_vf_vlan_filter_result {
+ cmdline_fixed_string_t set;
+ cmdline_fixed_string_t vf;
+ cmdline_fixed_string_t vlan;
+ cmdline_fixed_string_t filter;
+ uint8_t port_id;
+ uint16_t vlan_id;
+ uint16_t vf_mask;
+ cmdline_fixed_string_t on_off;
+};
+
+/* Common CLI fields for vf vlan filter enable disable */
+cmdline_parse_token_string_t cmd_vf_vlan_filter_set =
+ TOKEN_STRING_INITIALIZER
+ (struct cmd_vf_vlan_filter_result,
+ set, "set");
+cmdline_parse_token_string_t cmd_vf_vlan_filter_vf =
+ TOKEN_STRING_INITIALIZER
+ (struct cmd_vf_vlan_filter_result,
+ vf, "vf");
+cmdline_parse_token_string_t cmd_vf_vlan_filter_vlan =
+ TOKEN_STRING_INITIALIZER
+ (struct cmd_vf_vlan_filter_result,
+ vlan, "vlan");
+cmdline_parse_token_string_t cmd_vf_vlan_filter_filter =
+ TOKEN_STRING_INITIALIZER
+ (struct cmd_vf_vlan_filter_result,
+ filter, "filter");
+cmdline_parse_token_num_t cmd_vf_vlan_filter_port_id =
+ TOKEN_NUM_INITIALIZER
+ (struct cmd_vf_vlan_filter_result,
+ port_id, UINT8);
+cmdline_parse_token_num_t cmd_vf_vlan_filter_vlan_id =
+ TOKEN_NUM_INITIALIZER
+ (struct cmd_vf_vlan_filter_result,
+ vlan_id, UINT16);
+cmdline_parse_token_num_t cmd_vf_vlan_filter_vf_mask =
+ TOKEN_NUM_INITIALIZER
+ (struct cmd_vf_vlan_filter_result,
+ vf_mask, UINT16);
+cmdline_parse_token_string_t cmd_vf_vlan_filter_on_off =
+ TOKEN_STRING_INITIALIZER
+ (struct cmd_vf_vlan_filter_result,
+ on_off, "on#off");
+
+static void
+cmd_set_vf_vlan_filter_parsed(
+ void *parsed_result,
+ __attribute__((unused)) struct cmdline *cl,
+ __attribute__((unused)) void *data)
+{
+ struct cmd_vf_vlan_filter_result *res = parsed_result;
+ int ret;
+ int is_on = (strcmp(res->on_off, "on") == 0) ? 1 : 0;
+
+ ret = rte_pmd_ixgbe_set_vf_vlan_filter(res->port_id, res->vlan_id, res->vf_mask, is_on);
+ switch (ret) {
+ case 0:
+ break;
+ case -EINVAL:
+ printf("invalid vf_mask %d or vlan_id %d\n", res->vf_mask, res->vlan_id);
+ break;
+ case -ENODEV:
+ printf("invalid port_id %d\n", res->port_id);
+ break;
+ case -ENOTSUP:
+ printf("not supported on vf port %d\n", res->port_id);
+ break;
+ default:
+ printf("programming error: (%s)\n", strerror(-ret));
+ }
+}
+
+cmdline_parse_inst_t cmd_set_vf_vlan_filter = {
+ .f = cmd_set_vf_vlan_filter_parsed,
+ .data = NULL,
+ .help_str = "set vf vlan filter <port_id> <vlan_id> <vf_mask> on|off",
+ .tokens = {
+ (void *)&cmd_vf_vlan_filter_set,
+ (void *)&cmd_vf_vlan_filter_vf,
+ (void *)&cmd_vf_vlan_filter_vlan,
+ (void *)&cmd_vf_vlan_filter_filter,
+ (void *)&cmd_vf_vlan_filter_port_id,
+ (void *)&cmd_vf_vlan_filter_vlan_id,
+ (void *)&cmd_vf_vlan_filter_vf_mask,
+ (void *)&cmd_vf_vlan_filter_on_off,
+ NULL,
+ },
+};
+
/* tx loopback configuration */
/* Common result structure for tx loopback */
@@ -11620,6 +11717,7 @@ cmdline_parse_ctx_t main_ctx[] = {
(cmdline_parse_inst_t *)&cmd_set_vf_mac_anti_spoof,
(cmdline_parse_inst_t *)&cmd_set_vf_vlan_stripq,
(cmdline_parse_inst_t *)&cmd_set_vf_vlan_insert,
+ (cmdline_parse_inst_t *)&cmd_set_vf_vlan_filter,
(cmdline_parse_inst_t *)&cmd_set_tx_loopback,
(cmdline_parse_inst_t *)&cmd_set_all_queues_drop_en,
(cmdline_parse_inst_t *)&cmd_set_vf_split_drop_en,
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index f1c269a..60dcd91 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -535,6 +535,13 @@ Set VLAN insert for a VF from the PF::
testpmd> set vf vlan insert (port_id) (vf_id) (vlan_id)
+vlan set filter (for VF pool)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Set VLAN filter for a VF pool from the PF::
+
+ testpmd> set vf vlan filter (port_id) (vlan_id) (vf_mask) (on|off)
+
vlan set antispoof (for VF)
~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
2.10.1
^ permalink raw reply related
* [PATCH v2 4/9] app/testpmd: add command for set VF receive
From: Bernard Iremonger @ 2016-12-09 17:25 UTC (permalink / raw)
To: thomas.monjalon, dev; +Cc: Bernard Iremonger
In-Reply-To: <1481282878-26176-1-git-send-email-bernard.iremonger@intel.com>
add the following command to testpmd:
set vf rx <port_id> <vf_id> on|off
add command to the testpmd user guide.
Signed-off-by: Bernard Iremonger <bernard.iremonger@intel.com>
---
app/test-pmd/cmdline.c | 85 +++++++++++++++++++++++++++++
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 7 +++
2 files changed, 92 insertions(+)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 947c698..4424c0a 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -274,6 +274,9 @@ static void cmd_help_long_parsed(void *parsed_result,
"set vf mac antispoof (port_id) (vf_id) (on|off).\n"
" Set MAC antispoof for a VF from the PF.\n\n"
+
+ "set vf rx (port_id) (vf_id) (on|off).\n"
+ " Enable or disable RX for a VF from the PF.\n\n"
#endif
"vlan set strip (on|off) (port_id)\n"
@@ -11236,6 +11239,87 @@ cmdline_parse_inst_t cmd_set_vf_vlan_filter = {
},
};
+/* vf rx configuration */
+
+/* Common result structure for vf rx */
+struct cmd_vf_rx_result {
+ cmdline_fixed_string_t set;
+ cmdline_fixed_string_t vf;
+ cmdline_fixed_string_t rx;
+ uint8_t port_id;
+ uint16_t vf_id;
+ cmdline_fixed_string_t on_off;
+};
+
+/* Common CLI fields for vf rx enable disable */
+cmdline_parse_token_string_t cmd_vf_rx_set =
+ TOKEN_STRING_INITIALIZER
+ (struct cmd_vf_rx_result,
+ set, "set");
+cmdline_parse_token_string_t cmd_vf_rx_vf =
+ TOKEN_STRING_INITIALIZER
+ (struct cmd_vf_rx_result,
+ vf, "vf");
+cmdline_parse_token_string_t cmd_vf_rx_rx =
+ TOKEN_STRING_INITIALIZER
+ (struct cmd_vf_rx_result,
+ rx, "rx");
+cmdline_parse_token_num_t cmd_vf_rx_port_id =
+ TOKEN_NUM_INITIALIZER
+ (struct cmd_vf_rx_result,
+ port_id, UINT8);
+cmdline_parse_token_num_t cmd_vf_rx_vf_id =
+ TOKEN_NUM_INITIALIZER
+ (struct cmd_vf_rx_result,
+ vf_id, UINT16);
+cmdline_parse_token_string_t cmd_vf_rx_on_off =
+ TOKEN_STRING_INITIALIZER
+ (struct cmd_vf_rx_result,
+ on_off, "on#off");
+
+static void
+cmd_set_vf_rx_parsed(
+ void *parsed_result,
+ __attribute__((unused)) struct cmdline *cl,
+ __attribute__((unused)) void *data)
+{
+ struct cmd_vf_rx_result *res = parsed_result;
+ int ret = 0;
+ int is_on = (strcmp(res->on_off, "on") == 0) ? 1 : 0;
+
+ ret = rte_pmd_ixgbe_set_vf_rx(res->port_id, res->vf_id, is_on);
+ switch (ret) {
+ case 0:
+ break;
+ case -EINVAL:
+ printf("invalid vf_id %d or is_on %d\n", res->vf_id, is_on);
+ break;
+ case -ENODEV:
+ printf("invalid port_id %d\n", res->port_id);
+ break;
+ case -ENOTSUP:
+ printf("not supported on vf port %d\n", res->port_id);
+ break;
+ default:
+ printf("programming error: (%s)\n", strerror(-ret));
+ }
+}
+
+cmdline_parse_inst_t cmd_set_vf_rx = {
+ .f = cmd_set_vf_rx_parsed,
+ .data = NULL,
+ .help_str = "set vf rx <port_id> <vf_id> on|off",
+ .tokens = {
+ (void *)&cmd_vf_rx_set,
+ (void *)&cmd_vf_rx_vf,
+ (void *)&cmd_vf_rx_rx,
+ (void *)&cmd_vf_rx_port_id,
+ (void *)&cmd_vf_rx_vf_id,
+ (void *)&cmd_vf_rx_on_off,
+ NULL,
+ },
+};
+
/* tx loopback configuration */
/* Common result structure for tx loopback */
@@ -11722,6 +11806,7 @@ cmdline_parse_ctx_t main_ctx[] = {
(cmdline_parse_inst_t *)&cmd_set_all_queues_drop_en,
(cmdline_parse_inst_t *)&cmd_set_vf_split_drop_en,
(cmdline_parse_inst_t *)&cmd_set_vf_mac_addr,
+ (cmdline_parse_inst_t *)&cmd_set_vf_rx,
#endif
NULL,
};
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index 60dcd91..6a058e9 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -507,6 +507,13 @@ Set mac antispoof for a VF from the PF::
testpmd> set vf mac antispoof (port_id) (vf_id) (on|off)
+set rx (for VF)
+~~~~~~~~~~~~~~~
+
+Enable/disable rx for a VF from the PF::
+
+ testpmd> set vf rx (port_id) (vf_id) (on|off)
+
vlan set strip
~~~~~~~~~~~~~~
--
2.10.1
^ permalink raw reply related
* [PATCH v2 5/9] app/testpmd: add command for set VF transmit
From: Bernard Iremonger @ 2016-12-09 17:25 UTC (permalink / raw)
To: thomas.monjalon, dev; +Cc: Bernard Iremonger
In-Reply-To: <1481282878-26176-1-git-send-email-bernard.iremonger@intel.com>
add the following command to testpmd:
set vf tx <port_id> <vf_id> on|off
add command to the testpmd user guide.
Signed-off-by: Bernard Iremonger <bernard.iremonger@intel.com>
---
app/test-pmd/cmdline.c | 85 +++++++++++++++++++++++++++++
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 7 +++
2 files changed, 92 insertions(+)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 4424c0a..e385732 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -277,6 +277,9 @@ static void cmd_help_long_parsed(void *parsed_result,
"set vf rx (port_id) (vf_id) (on|off).\n"
" Enable or disable RX for a VF from the PF.\n\n"
+
+ "set vf tx (port_id) (vf_id) (on|off).\n"
+ " Enable or disable TX for a VF from the PF.\n\n"
#endif
"vlan set strip (on|off) (port_id)\n"
@@ -11320,6 +11323,87 @@ cmdline_parse_inst_t cmd_set_vf_rx = {
},
};
+/* vf tx configuration */
+
+/* Common result structure for vf tx */
+struct cmd_vf_tx_result {
+ cmdline_fixed_string_t set;
+ cmdline_fixed_string_t vf;
+ cmdline_fixed_string_t tx;
+ uint8_t port_id;
+ uint16_t vf_id;
+ cmdline_fixed_string_t on_off;
+};
+
+/* Common CLI fields for vf tx enable disable */
+cmdline_parse_token_string_t cmd_vf_tx_set =
+ TOKEN_STRING_INITIALIZER
+ (struct cmd_vf_tx_result,
+ set, "set");
+cmdline_parse_token_string_t cmd_vf_tx_vf =
+ TOKEN_STRING_INITIALIZER
+ (struct cmd_vf_tx_result,
+ vf, "vf");
+cmdline_parse_token_string_t cmd_vf_tx_tx =
+ TOKEN_STRING_INITIALIZER
+ (struct cmd_vf_tx_result,
+ tx, "tx");
+cmdline_parse_token_num_t cmd_vf_tx_port_id =
+ TOKEN_NUM_INITIALIZER
+ (struct cmd_vf_tx_result,
+ port_id, UINT8);
+cmdline_parse_token_num_t cmd_vf_tx_vf_id =
+ TOKEN_NUM_INITIALIZER
+ (struct cmd_vf_tx_result,
+ vf_id, UINT16);
+cmdline_parse_token_string_t cmd_vf_tx_on_off =
+ TOKEN_STRING_INITIALIZER
+ (struct cmd_vf_tx_result,
+ on_off, "on#off");
+
+static void
+cmd_set_vf_tx_parsed(
+ void *parsed_result,
+ __attribute__((unused)) struct cmdline *cl,
+ __attribute__((unused)) void *data)
+{
+ struct cmd_vf_tx_result *res = parsed_result;
+ int ret = 0;
+ int is_on = (strcmp(res->on_off, "on") == 0) ? 1 : 0;
+
+ ret = rte_pmd_ixgbe_set_vf_tx(res->port_id, res->vf_id, is_on);
+ switch (ret) {
+ case 0:
+ break;
+ case -EINVAL:
+ printf("invalid vf_id %d or is_on %d\n", res->vf_id, is_on);
+ break;
+ case -ENODEV:
+ printf("invalid port_id %d\n", res->port_id);
+ break;
+ case -ENOTSUP:
+ printf("not supported on vf port %d\n", res->port_id);
+ break;
+ default:
+ printf("programming error: (%s)\n", strerror(-ret));
+ }
+}
+
+cmdline_parse_inst_t cmd_set_vf_tx = {
+ .f = cmd_set_vf_tx_parsed,
+ .data = NULL,
+ .help_str = "set vf tx <port_id> <vf_id> on|off",
+ .tokens = {
+ (void *)&cmd_vf_tx_set,
+ (void *)&cmd_vf_tx_vf,
+ (void *)&cmd_vf_tx_tx,
+ (void *)&cmd_vf_tx_port_id,
+ (void *)&cmd_vf_tx_vf_id,
+ (void *)&cmd_vf_tx_on_off,
+ NULL,
+ },
+};
+
/* tx loopback configuration */
/* Common result structure for tx loopback */
@@ -11807,6 +11891,7 @@ cmdline_parse_ctx_t main_ctx[] = {
(cmdline_parse_inst_t *)&cmd_set_vf_split_drop_en,
(cmdline_parse_inst_t *)&cmd_set_vf_mac_addr,
(cmdline_parse_inst_t *)&cmd_set_vf_rx,
+ (cmdline_parse_inst_t *)&cmd_set_vf_tx,
#endif
NULL,
};
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index 6a058e9..1de4c5f 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -514,6 +514,13 @@ Enable/disable rx for a VF from the PF::
testpmd> set vf rx (port_id) (vf_id) (on|off)
+set tx (for VF)
+~~~~~~~~~~~~~~~
+
+Enable/disable tx for a VF from the PF::
+
+ testpmd> set vf tx (port_id) (vf_id) (on|off)
+
vlan set strip
~~~~~~~~~~~~~~
--
2.10.1
^ permalink raw reply related
* [PATCH v2 6/9] examples/ethtool: use ixgbe public function
From: Bernard Iremonger @ 2016-12-09 17:25 UTC (permalink / raw)
To: thomas.monjalon, dev; +Cc: Bernard Iremonger
In-Reply-To: <1481282878-26176-1-git-send-email-bernard.iremonger@intel.com>
Replace rte_eth_dev_set_vf_rxmode with rte_pmd_ixgbe_set_vf_rx_mode.
Signed-off-by: Bernard Iremonger <bernard.iremonger@intel.com>
---
examples/ethtool/lib/rte_ethtool.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/examples/ethtool/lib/rte_ethtool.c b/examples/ethtool/lib/rte_ethtool.c
index a1f91d4..0e539f7 100644
--- a/examples/ethtool/lib/rte_ethtool.c
+++ b/examples/ethtool/lib/rte_ethtool.c
@@ -1,7 +1,7 @@
/*-
* BSD LICENSE
*
- * Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
+ * Copyright(c) 2010-2016 Intel Corporation. All rights reserved.
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -36,6 +36,7 @@
#include <rte_version.h>
#include <rte_ethdev.h>
#include <rte_ether.h>
+#include <rte_pmd_ixgbe.h>
#include "rte_ethtool.h"
#define PKTPOOL_SIZE 512
@@ -354,7 +355,7 @@ rte_ethtool_net_set_rx_mode(uint8_t port_id)
/* Set VF vf_rx_mode, VF unsupport status is discard */
for (vf = 0; vf < num_vfs; vf++)
- rte_eth_dev_set_vf_rxmode(port_id, vf,
+ rte_pmd_ixgbe_set_vf_rxmode(port_id, vf,
ETH_VMDQ_ACCEPT_UNTAG, 0);
/* Enable Rx vlan filter, VF unspport status is discard */
--
2.10.1
^ permalink raw reply related
* [PATCH v2 7/9] net/ixgbe: remove static set VF functions
From: Bernard Iremonger @ 2016-12-09 17:25 UTC (permalink / raw)
To: thomas.monjalon, dev; +Cc: Bernard Iremonger
In-Reply-To: <1481282878-26176-1-git-send-email-bernard.iremonger@intel.com>
remove the following static functions:
ixgbe_set_pool_rx_mode
ixgbe_set_pool_rx
ixgbe_set_pool_tx
ixgbe_set_pool_vlan_filter
ixgbe_set_vf_rate_limit
Signed-off-by: Bernard Iremonger <bernard.iremonger@intel.com>
---
drivers/net/ixgbe/ixgbe_ethdev.c | 193 ---------------------------------------
1 file changed, 193 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index 37b82a4..8db1410 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -276,12 +276,6 @@ static void ixgbevf_dev_allmulticast_disable(struct rte_eth_dev *dev);
static int ixgbe_uc_hash_table_set(struct rte_eth_dev *dev, struct
ether_addr * mac_addr, uint8_t on);
static int ixgbe_uc_all_hash_table_set(struct rte_eth_dev *dev, uint8_t on);
-static int ixgbe_set_pool_rx_mode(struct rte_eth_dev *dev, uint16_t pool,
- uint16_t rx_mask, uint8_t on);
-static int ixgbe_set_pool_rx(struct rte_eth_dev *dev, uint16_t pool, uint8_t on);
-static int ixgbe_set_pool_tx(struct rte_eth_dev *dev, uint16_t pool, uint8_t on);
-static int ixgbe_set_pool_vlan_filter(struct rte_eth_dev *dev, uint16_t vlan,
- uint64_t pool_mask, uint8_t vlan_on);
static int ixgbe_mirror_rule_set(struct rte_eth_dev *dev,
struct rte_eth_mirror_conf *mirror_conf,
uint8_t rule_id, uint8_t on);
@@ -297,8 +291,6 @@ static void ixgbe_configure_msix(struct rte_eth_dev *dev);
static int ixgbe_set_queue_rate_limit(struct rte_eth_dev *dev,
uint16_t queue_idx, uint16_t tx_rate);
-static int ixgbe_set_vf_rate_limit(struct rte_eth_dev *dev, uint16_t vf,
- uint16_t tx_rate, uint64_t q_msk);
static void ixgbevf_add_mac_addr(struct rte_eth_dev *dev,
struct ether_addr *mac_addr,
@@ -568,12 +560,7 @@ static const struct eth_dev_ops ixgbe_eth_dev_ops = {
.uc_all_hash_table_set = ixgbe_uc_all_hash_table_set,
.mirror_rule_set = ixgbe_mirror_rule_set,
.mirror_rule_reset = ixgbe_mirror_rule_reset,
- .set_vf_rx_mode = ixgbe_set_pool_rx_mode,
- .set_vf_rx = ixgbe_set_pool_rx,
- .set_vf_tx = ixgbe_set_pool_tx,
- .set_vf_vlan_filter = ixgbe_set_pool_vlan_filter,
.set_queue_rate_limit = ixgbe_set_queue_rate_limit,
- .set_vf_rate_limit = ixgbe_set_vf_rate_limit,
.reta_update = ixgbe_dev_rss_reta_update,
.reta_query = ixgbe_dev_rss_reta_query,
#ifdef RTE_NIC_BYPASS
@@ -4547,132 +4534,6 @@ ixgbe_convert_vm_rx_mask_to_val(uint16_t rx_mask, uint32_t orig_val)
return new_val;
}
-static int
-ixgbe_set_pool_rx_mode(struct rte_eth_dev *dev, uint16_t pool,
- uint16_t rx_mask, uint8_t on)
-{
- int val = 0;
-
- struct ixgbe_hw *hw =
- IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
- uint32_t vmolr = IXGBE_READ_REG(hw, IXGBE_VMOLR(pool));
-
- if (hw->mac.type == ixgbe_mac_82598EB) {
- PMD_INIT_LOG(ERR, "setting VF receive mode set should be done"
- " on 82599 hardware and newer");
- return -ENOTSUP;
- }
- if (ixgbe_vmdq_mode_check(hw) < 0)
- return -ENOTSUP;
-
- val = ixgbe_convert_vm_rx_mask_to_val(rx_mask, val);
-
- if (on)
- vmolr |= val;
- else
- vmolr &= ~val;
-
- IXGBE_WRITE_REG(hw, IXGBE_VMOLR(pool), vmolr);
-
- return 0;
-}
-
-static int
-ixgbe_set_pool_rx(struct rte_eth_dev *dev, uint16_t pool, uint8_t on)
-{
- uint32_t reg, addr;
- uint32_t val;
- const uint8_t bit1 = 0x1;
-
- struct ixgbe_hw *hw =
- IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
-
- if (ixgbe_vmdq_mode_check(hw) < 0)
- return -ENOTSUP;
-
- if (pool >= ETH_64_POOLS)
- return -EINVAL;
-
- /* for pool >= 32, set bit in PFVFRE[1], otherwise PFVFRE[0] */
- if (pool >= 32) {
- addr = IXGBE_VFRE(1);
- val = bit1 << (pool - 32);
- } else {
- addr = IXGBE_VFRE(0);
- val = bit1 << pool;
- }
-
- reg = IXGBE_READ_REG(hw, addr);
-
- if (on)
- reg |= val;
- else
- reg &= ~val;
-
- IXGBE_WRITE_REG(hw, addr, reg);
-
- return 0;
-}
-
-static int
-ixgbe_set_pool_tx(struct rte_eth_dev *dev, uint16_t pool, uint8_t on)
-{
- uint32_t reg, addr;
- uint32_t val;
- const uint8_t bit1 = 0x1;
-
- struct ixgbe_hw *hw =
- IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
-
- if (ixgbe_vmdq_mode_check(hw) < 0)
- return -ENOTSUP;
-
- if (pool >= ETH_64_POOLS)
- return -EINVAL;
-
- /* for pool >= 32, set bit in PFVFTE[1], otherwise PFVFTE[0] */
- if (pool >= 32) {
- addr = IXGBE_VFTE(1);
- val = bit1 << (pool - 32);
- } else {
- addr = IXGBE_VFTE(0);
- val = bit1 << pool;
- }
-
- reg = IXGBE_READ_REG(hw, addr);
-
- if (on)
- reg |= val;
- else
- reg &= ~val;
-
- IXGBE_WRITE_REG(hw, addr, reg);
-
- return 0;
-}
-
-static int
-ixgbe_set_pool_vlan_filter(struct rte_eth_dev *dev, uint16_t vlan,
- uint64_t pool_mask, uint8_t vlan_on)
-{
- int ret = 0;
- uint16_t pool_idx;
- struct ixgbe_hw *hw =
- IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
-
- if (ixgbe_vmdq_mode_check(hw) < 0)
- return -ENOTSUP;
- for (pool_idx = 0; pool_idx < ETH_64_POOLS; pool_idx++) {
- if (pool_mask & ((uint64_t)(1ULL << pool_idx))) {
- ret = hw->mac.ops.set_vfta(hw, vlan, pool_idx,
- vlan_on, false);
- if (ret < 0)
- return ret;
- }
- }
-
- return ret;
-}
int
rte_pmd_ixgbe_set_vf_vlan_anti_spoof(uint8_t port, uint16_t vf, uint8_t on)
@@ -5628,60 +5489,6 @@ static int ixgbe_set_queue_rate_limit(struct rte_eth_dev *dev,
return 0;
}
-static int ixgbe_set_vf_rate_limit(struct rte_eth_dev *dev, uint16_t vf,
- uint16_t tx_rate, uint64_t q_msk)
-{
- struct ixgbe_hw *hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
- struct ixgbe_vf_info *vfinfo =
- *(IXGBE_DEV_PRIVATE_TO_P_VFDATA(dev->data->dev_private));
- uint8_t nb_q_per_pool = RTE_ETH_DEV_SRIOV(dev).nb_q_per_pool;
- uint32_t queue_stride =
- IXGBE_MAX_RX_QUEUE_NUM / RTE_ETH_DEV_SRIOV(dev).active;
- uint32_t queue_idx = vf * queue_stride, idx = 0, vf_idx;
- uint32_t queue_end = queue_idx + nb_q_per_pool - 1;
- uint16_t total_rate = 0;
-
- if (queue_end >= hw->mac.max_tx_queues)
- return -EINVAL;
-
- if (vfinfo != NULL) {
- for (vf_idx = 0; vf_idx < dev->pci_dev->max_vfs; vf_idx++) {
- if (vf_idx == vf)
- continue;
- for (idx = 0; idx < RTE_DIM(vfinfo[vf_idx].tx_rate);
- idx++)
- total_rate += vfinfo[vf_idx].tx_rate[idx];
- }
- } else
- return -EINVAL;
-
- /* Store tx_rate for this vf. */
- for (idx = 0; idx < nb_q_per_pool; idx++) {
- if (((uint64_t)0x1 << idx) & q_msk) {
- if (vfinfo[vf].tx_rate[idx] != tx_rate)
- vfinfo[vf].tx_rate[idx] = tx_rate;
- total_rate += tx_rate;
- }
- }
-
- if (total_rate > dev->data->dev_link.link_speed) {
- /*
- * Reset stored TX rate of the VF if it causes exceed
- * link speed.
- */
- memset(vfinfo[vf].tx_rate, 0, sizeof(vfinfo[vf].tx_rate));
- return -EINVAL;
- }
-
- /* Set RTTBCNRC of each queue/pool for vf X */
- for (; queue_idx <= queue_end; queue_idx++) {
- if (0x1 & q_msk)
- ixgbe_set_queue_rate_limit(dev, queue_idx, tx_rate);
- q_msk = q_msk >> 1;
- }
-
- return 0;
-}
static void
ixgbevf_add_mac_addr(struct rte_eth_dev *dev, struct ether_addr *mac_addr,
--
2.10.1
^ permalink raw reply related
* [PATCH v2 8/9] librte_ether: remove the set VF API's
From: Bernard Iremonger @ 2016-12-09 17:26 UTC (permalink / raw)
To: thomas.monjalon, dev; +Cc: Bernard Iremonger
In-Reply-To: <1481282878-26176-1-git-send-email-bernard.iremonger@intel.com>
remove the following API's:
rte_eth_dev_set_vf_rxmode
rte_eth_dev_set_vf_rx
rte_eth_dev_set_vf_tx
rte_eth_dev_set_vf_vlan_filter
rte_eth_dev_set_vf_rate_limit
Signed-off-by: Bernard Iremonger <bernard.iremonger@intel.com>
---
lib/librte_ether/rte_ethdev.c | 129 ------------------------------------------
lib/librte_ether/rte_ethdev.h | 33 -----------
2 files changed, 162 deletions(-)
diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index 1e0f206..6a93014 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -2137,32 +2137,6 @@ rte_eth_dev_default_mac_addr_set(uint8_t port_id, struct ether_addr *addr)
return 0;
}
-int
-rte_eth_dev_set_vf_rxmode(uint8_t port_id, uint16_t vf,
- uint16_t rx_mode, uint8_t on)
-{
- uint16_t num_vfs;
- struct rte_eth_dev *dev;
- struct rte_eth_dev_info dev_info;
-
- RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
-
- dev = &rte_eth_devices[port_id];
- rte_eth_dev_info_get(port_id, &dev_info);
-
- num_vfs = dev_info.max_vfs;
- if (vf > num_vfs) {
- RTE_PMD_DEBUG_TRACE("set VF RX mode:invalid VF id %d\n", vf);
- return -EINVAL;
- }
-
- if (rx_mode == 0) {
- RTE_PMD_DEBUG_TRACE("set VF RX mode:mode mask ca not be zero\n");
- return -EINVAL;
- }
- RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->set_vf_rx_mode, -ENOTSUP);
- return (*dev->dev_ops->set_vf_rx_mode)(dev, vf, rx_mode, on);
-}
/*
* Returns index into MAC address array of addr. Use 00:00:00:00:00:00 to find
@@ -2252,76 +2226,6 @@ rte_eth_dev_uc_all_hash_table_set(uint8_t port_id, uint8_t on)
return (*dev->dev_ops->uc_all_hash_table_set)(dev, on);
}
-int
-rte_eth_dev_set_vf_rx(uint8_t port_id, uint16_t vf, uint8_t on)
-{
- uint16_t num_vfs;
- struct rte_eth_dev *dev;
- struct rte_eth_dev_info dev_info;
-
- RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
-
- dev = &rte_eth_devices[port_id];
- rte_eth_dev_info_get(port_id, &dev_info);
-
- num_vfs = dev_info.max_vfs;
- if (vf > num_vfs) {
- RTE_PMD_DEBUG_TRACE("port %d: invalid vf id\n", port_id);
- return -EINVAL;
- }
-
- RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->set_vf_rx, -ENOTSUP);
- return (*dev->dev_ops->set_vf_rx)(dev, vf, on);
-}
-
-int
-rte_eth_dev_set_vf_tx(uint8_t port_id, uint16_t vf, uint8_t on)
-{
- uint16_t num_vfs;
- struct rte_eth_dev *dev;
- struct rte_eth_dev_info dev_info;
-
- RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
-
- dev = &rte_eth_devices[port_id];
- rte_eth_dev_info_get(port_id, &dev_info);
-
- num_vfs = dev_info.max_vfs;
- if (vf > num_vfs) {
- RTE_PMD_DEBUG_TRACE("set pool tx:invalid pool id=%d\n", vf);
- return -EINVAL;
- }
-
- RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->set_vf_tx, -ENOTSUP);
- return (*dev->dev_ops->set_vf_tx)(dev, vf, on);
-}
-
-int
-rte_eth_dev_set_vf_vlan_filter(uint8_t port_id, uint16_t vlan_id,
- uint64_t vf_mask, uint8_t vlan_on)
-{
- struct rte_eth_dev *dev;
-
- RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
-
- dev = &rte_eth_devices[port_id];
-
- if (vlan_id > ETHER_MAX_VLAN_ID) {
- RTE_PMD_DEBUG_TRACE("VF VLAN filter:invalid VLAN id=%d\n",
- vlan_id);
- return -EINVAL;
- }
-
- if (vf_mask == 0) {
- RTE_PMD_DEBUG_TRACE("VF VLAN filter:pool_mask can not be 0\n");
- return -EINVAL;
- }
-
- RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->set_vf_vlan_filter, -ENOTSUP);
- return (*dev->dev_ops->set_vf_vlan_filter)(dev, vlan_id,
- vf_mask, vlan_on);
-}
-
int rte_eth_set_queue_rate_limit(uint8_t port_id, uint16_t queue_idx,
uint16_t tx_rate)
{
@@ -2352,39 +2256,6 @@ int rte_eth_set_queue_rate_limit(uint8_t port_id, uint16_t queue_idx,
return (*dev->dev_ops->set_queue_rate_limit)(dev, queue_idx, tx_rate);
}
-int rte_eth_set_vf_rate_limit(uint8_t port_id, uint16_t vf, uint16_t tx_rate,
- uint64_t q_msk)
-{
- struct rte_eth_dev *dev;
- struct rte_eth_dev_info dev_info;
- struct rte_eth_link link;
-
- if (q_msk == 0)
- return 0;
-
- RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
-
- dev = &rte_eth_devices[port_id];
- rte_eth_dev_info_get(port_id, &dev_info);
- link = dev->data->dev_link;
-
- if (vf > dev_info.max_vfs) {
- RTE_PMD_DEBUG_TRACE("set VF rate limit:port %d: "
- "invalid vf id=%d\n", port_id, vf);
- return -EINVAL;
- }
-
- if (tx_rate > link.link_speed) {
- RTE_PMD_DEBUG_TRACE("set VF rate limit:invalid tx_rate=%d, "
- "bigger than link speed= %d\n",
- tx_rate, link.link_speed);
- return -EINVAL;
- }
-
- RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->set_vf_rate_limit, -ENOTSUP);
- return (*dev->dev_ops->set_vf_rate_limit)(dev, vf, tx_rate, q_msk);
-}
-
int
rte_eth_mirror_rule_set(uint8_t port_id,
struct rte_eth_mirror_conf *mirror_conf,
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index 9678179..269ac77 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -1249,39 +1249,11 @@ typedef int (*eth_uc_all_hash_table_set_t)(struct rte_eth_dev *dev,
uint8_t on);
/**< @internal Set all Unicast Hash bitmap */
-typedef int (*eth_set_vf_rx_mode_t)(struct rte_eth_dev *dev,
- uint16_t vf,
- uint16_t rx_mode,
- uint8_t on);
-/**< @internal Set a VF receive mode */
-
-typedef int (*eth_set_vf_rx_t)(struct rte_eth_dev *dev,
- uint16_t vf,
- uint8_t on);
-/**< @internal Set a VF receive mode */
-
-typedef int (*eth_set_vf_tx_t)(struct rte_eth_dev *dev,
- uint16_t vf,
- uint8_t on);
-/**< @internal Enable or disable a VF transmit */
-
-typedef int (*eth_set_vf_vlan_filter_t)(struct rte_eth_dev *dev,
- uint16_t vlan,
- uint64_t vf_mask,
- uint8_t vlan_on);
-/**< @internal Set VF VLAN pool filter */
-
typedef int (*eth_set_queue_rate_limit_t)(struct rte_eth_dev *dev,
uint16_t queue_idx,
uint16_t tx_rate);
/**< @internal Set queue TX rate */
-typedef int (*eth_set_vf_rate_limit_t)(struct rte_eth_dev *dev,
- uint16_t vf,
- uint16_t tx_rate,
- uint64_t q_msk);
-/**< @internal Set VF TX rate */
-
typedef int (*eth_mirror_rule_set_t)(struct rte_eth_dev *dev,
struct rte_eth_mirror_conf *mirror_conf,
uint8_t rule_id,
@@ -1479,16 +1451,11 @@ struct eth_dev_ops {
eth_uc_all_hash_table_set_t uc_all_hash_table_set; /**< Set Unicast hash bitmap */
eth_mirror_rule_set_t mirror_rule_set; /**< Add a traffic mirror rule.*/
eth_mirror_rule_reset_t mirror_rule_reset; /**< reset a traffic mirror rule.*/
- eth_set_vf_rx_mode_t set_vf_rx_mode; /**< Set VF RX mode */
- eth_set_vf_rx_t set_vf_rx; /**< enable/disable a VF receive */
- eth_set_vf_tx_t set_vf_tx; /**< enable/disable a VF transmit */
- eth_set_vf_vlan_filter_t set_vf_vlan_filter; /**< Set VF VLAN filter */
/** Add UDP tunnel port. */
eth_udp_tunnel_port_add_t udp_tunnel_port_add;
/** Del UDP tunnel port. */
eth_udp_tunnel_port_del_t udp_tunnel_port_del;
eth_set_queue_rate_limit_t set_queue_rate_limit; /**< Set queue rate limit */
- eth_set_vf_rate_limit_t set_vf_rate_limit; /**< Set VF rate limit */
/** Update redirection table. */
reta_update_t reta_update;
/** Query redirection table. */
--
2.10.1
^ permalink raw reply related
* [PATCH v2 9/9] doc: remove deprecation notice
From: Bernard Iremonger @ 2016-12-09 17:26 UTC (permalink / raw)
To: thomas.monjalon, dev; +Cc: Bernard Iremonger
In-Reply-To: <1481282878-26176-1-git-send-email-bernard.iremonger@intel.com>
remove deprecation notice for removing rte_eth_dev_set_vf_* API's.
Signed-off-by: Bernard Iremonger <bernard.iremonger@intel.com>
---
doc/guides/rel_notes/deprecation.rst | 13 -------------
1 file changed, 13 deletions(-)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 2d17bc6..c897c18 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -38,19 +38,6 @@ Deprecation Notices
``_rte_eth_dev_callback_process``. In 17.02 the function will return an ``int``
instead of ``void`` and a fourth parameter ``void *ret_param`` will be added.
-* ethdev: for 17.02 it is planned to deprecate the following five functions
- and move them in ixgbe:
-
- ``rte_eth_dev_set_vf_rxmode``
-
- ``rte_eth_dev_set_vf_rx``
-
- ``rte_eth_dev_set_vf_tx``
-
- ``rte_eth_dev_set_vf_vlan_filter``
-
- ``rte_eth_set_vf_rate_limit``
-
* ABI changes are planned for 17.02 in the ``rte_mbuf`` structure: some fields
may be reordered to facilitate the writing of ``data_off``, ``refcnt``, and
``nb_segs`` in one operation, because some platforms have an overhead if the
--
2.10.1
^ permalink raw reply related
* Re: [PATCH 00/31] Support more features in Solarflare PMD
From: Ferruh Yigit @ 2016-12-09 17:34 UTC (permalink / raw)
To: Andrew Rybchenko, dev
In-Reply-To: <1480664691-26561-1-git-send-email-arybchenko@solarflare.com>
On 12/2/2016 7:44 AM, Andrew Rybchenko wrote:
> The patch series adds a number of features to Solarflare libefx-based
> PMD. Basically one patch per feature.
>
> The patches are grouped into one series since they touch nearby lines
> in either PMD feature list, or dev_ops structure, or documentation.
> So, patches cannot be applied in arbitrary order.
>
> The patch series should be applied after
> [PATCH v2 00/55] Solarflare libefx-based PMD
> (Message-ID: 1480436367-20749-1-git-send-email-arybchenko@solarflare.com)
>
>
> Andrew Rybchenko (16):
> net/sfc: implement MCDI logging callback
> net/sfc: support parameter to choose performance profile
> net/sfc: implement ethdev hook to get basic statistics
> net/sfc: support extended statistics
> net/sfc: support flow control settings get/set
> net/sfc: support link status change interrupt
> net/sfc: implement device operation to change MTU
> net/sfc: support link speed and duplex settings
> net/sfc: support checksum offloads on receive
> net/sfc: handle received packet type info provided by HW
> net/sfc: support callback to get receive queue information
> net/sfc: support Rx free threshold
> net/sfc: add callback to get RxQ pending descriptors count
> net/sfc: add RxQ descriptor done callback
> net/sfc: support scattered Rx DMA
> net/sfc: support deferred start of receive queues
>
> Artem Andreev (1):
> net/sfc: support link up/down
>
> Ivan Malov (14):
> net/sfc: support promiscuous and all-multicast control
> net/sfc: support main (the first) MAC address change
> net/sfc: support multicast addresses list controls
> net/sfc: add callback to get transmit queue information
> net/sfc: support Tx free threshold
> net/sfc: support deferred start of transmit queues
> net/sfc: support VLAN offload on transmit path
> net/sfc: add basic stubs for RSS support on driver attach
> net/sfc: support RSS hash offload
> net/sfc: add callback to query RSS key and hash types config
> net/sfc: add callback to set RSS key and hash types config
> net/sfc: add callback to query RSS redirection table
> net/sfc: add callback to update RSS redirection table
> net/sfc: support firmware-assisted TSOv2
Hi Andrew,
I am getting following build errors for clang [1] and ICC [2]. I have
not investigated the root cause, just copy-pasting here.
For ICC, since you explicitly noted it is not supported, and reported
warning is known, I believe it is safe the ignore this warning via
"-wd188" CFLAGS option in the Makefile.
Thanks,
ferruh
[1] clang
.../drivers/net/sfc/sfc_ethdev.c:1143:4: error: format specifies type
'unsigned short' but the argument has type 'int' [-Werror,-Wformat]
EFX_RSS_TBL_SIZE);
^~~~~~~~~~~~~~~~
.../drivers/net/sfc/base/efx.h:1866:26: note: expanded from macro
'EFX_RSS_TBL_SIZE'
#define EFX_RSS_TBL_SIZE 128 /* Rows in RX indirection table */
^~~
.../drivers/net/sfc/sfc_log.h:51:19: note: expanded from macro 'sfc_err'
SFC_LOG(sa, ERR, __VA_ARGS__)
^~~~~~~~~~~
.../drivers/net/sfc/sfc_log.h:47:18: note: expanded from macro 'SFC_LOG'
RTE_FMT_TAIL(__VA_ARGS__,))); \
^~~~~~~~~~~
.../x86_64-native-linuxapp-clang/include/rte_common.h:345:32: note:
expanded from macro 'RTE_FMT_TAIL'
#define RTE_FMT_TAIL(fmt, ...) __VA_ARGS__
^~~~~~~~~~~
.../x86_64-native-linuxapp-clang/include/rte_common.h:343:39: note:
expanded from macro 'RTE_FMT'
#define RTE_FMT(fmt, ...) fmt "%.0s", __VA_ARGS__ ""
^~~~~~~~~~~
.../x86_64-native-linuxapp-clang/include/rte_log.h:258:32: note:
expanded from macro 'RTE_LOG'
RTE_LOGTYPE_ ## t, # t ": " __VA_ARGS__)
^~~~~~~~~~~
[2] ICC
.../drivers/net/sfc/sfc_ethdev.c(1063): error #188: enumerated type
mixed with another type
efx_hash_types, B_TRUE);
^
.../drivers/net/sfc/sfc_ethdev.c(1086): error #188: enumerated type
mixed with another type
sa->rss_hash_types, B_TRUE) != 0)
^
compilation aborted for .../drivers/net/sfc/sfc_ethdev.c (code 2)
make[7]: *** [sfc_ethdev.o] Error 2
make[7]: *** Waiting for unfinished jobs....
.../drivers/net/sfc/sfc_rx.c(820): error #188: enumerated type mixed
with another type
sa->rss_hash_types, B_TRUE);
^
compilation aborted for .../drivers/net/sfc/sfc_rx.c (code 2)
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox