* Re: [PATCH v6 01/17] net/i40e: store ethertype filter
From: Ferruh Yigit @ 2017-01-05 17:46 UTC (permalink / raw)
To: Beilei Xing, jingjing.wu, helin.zhang; +Cc: dev
In-Reply-To: <1483631170-16681-2-git-send-email-beilei.xing@intel.com>
On 1/5/2017 3:45 PM, Beilei Xing wrote:
> Currently there's no ethertype filter stored in SW.
> This patch stores ethertype filter with cuckoo hash
> in SW, also adds protection if an ethertype filter
> has been added.
>
> Signed-off-by: Beilei Xing <beilei.xing@intel.com>
> ---
<...>
> @@ -939,9 +946,18 @@ eth_i40e_dev_init(struct rte_eth_dev *dev)
> int ret;
> uint32_t len;
> uint8_t aq_fail = 0;
> + struct i40e_ethertype_rule *ethertype_rule = &pf->ethertype;
>
> PMD_INIT_FUNC_TRACE();
>
> + char ethertype_hash_name[RTE_HASH_NAMESIZE];
> + struct rte_hash_parameters ethertype_hash_params = {
> + .name = ethertype_hash_name,
> + .entries = I40E_MAX_ETHERTYPE_FILTER_NUM,
> + .key_len = sizeof(struct i40e_ethertype_filter_input),
> + .hash_func = rte_hash_crc,
> + };
> +
> dev->dev_ops = &i40e_eth_dev_ops;
> dev->rx_pkt_burst = i40e_recv_pkts;
> dev->tx_pkt_burst = i40e_xmit_pkts;
> @@ -1182,8 +1198,33 @@ eth_i40e_dev_init(struct rte_eth_dev *dev)
> pf->flags &= ~I40E_FLAG_DCB;
> }
>
> + /* Initialize ethertype filter rule list and hash */
> + TAILQ_INIT(ðertype_rule->ethertype_list);
> + snprintf(ethertype_hash_name, RTE_HASH_NAMESIZE,
> + "ethertype_%s", dev->data->name);
> + ethertype_rule->hash_table = rte_hash_create(ðertype_hash_params);
> + if (!ethertype_rule->hash_table) {
> + PMD_INIT_LOG(ERR, "Failed to create ethertype hash table!");
> + ret = -EINVAL;
> + goto err_ethertype_hash_table_create;
> + }
> + ethertype_rule->hash_map = rte_zmalloc("i40e_ethertype_hash_map",
> + sizeof(struct i40e_ethertype_filter *) *
> + I40E_MAX_ETHERTYPE_FILTER_NUM,
> + 0);
> + if (!ethertype_rule->hash_map) {
> + PMD_INIT_LOG(ERR,
> + "Failed to allocate memory for ethertype hash map!");
> + ret = -ENOMEM;
> + goto err_ethertype_hash_map_alloc;
> + }
> +
> return 0;
>
> +err_ethertype_hash_map_alloc:
> + rte_hash_free(ethertype_rule->hash_table);
> +err_ethertype_hash_table_create:
> + rte_free(dev->data->mac_addrs);
> err_mac_alloc:
> i40e_vsi_release(pf->main_vsi);
> err_setup_pf_switch:
It can be good idea to extract filter related code into a separate
function, eth_i40e_dev_init() is already too big. It is up to you.
> @@ -1206,25 +1247,42 @@ eth_i40e_dev_init(struct rte_eth_dev *dev)
> static int
> eth_i40e_dev_uninit(struct rte_eth_dev *dev)
> {
> + struct i40e_pf *pf;
> struct rte_pci_device *pci_dev;
> struct rte_intr_handle *intr_handle;
> struct i40e_hw *hw;
> struct i40e_filter_control_settings settings;
> + struct i40e_ethertype_filter *p_ethertype;
> int ret;
> uint8_t aq_fail = 0;
> + struct i40e_ethertype_rule *ethertype_rule;
>
> PMD_INIT_FUNC_TRACE();
>
> if (rte_eal_process_type() != RTE_PROC_PRIMARY)
> return 0;
>
> + pf = I40E_DEV_PRIVATE_TO_PF(dev->data->dev_private);
> hw = I40E_DEV_PRIVATE_TO_HW(dev->data->dev_private);
> pci_dev = I40E_DEV_TO_PCI(dev);
> intr_handle = &pci_dev->intr_handle;
> + ethertype_rule = &pf->ethertype;
>
> if (hw->adapter_stopped == 0)
> i40e_dev_close(dev);
>
> + /* Remove all ethertype director rules and hash */
> + if (ethertype_rule->hash_map)
> + rte_free(ethertype_rule->hash_map);
> + if (ethertype_rule->hash_table)
> + rte_hash_free(ethertype_rule->hash_table);
> +
> + while ((p_ethertype = TAILQ_FIRST(ðertype_rule->ethertype_list))) {
> + TAILQ_REMOVE(ðertype_rule->ethertype_list,
> + p_ethertype, rules);
> + rte_free(p_ethertype);
> + }
> +
> dev->dev_ops = NULL;
> dev->rx_pkt_burst = NULL;
> dev->tx_pkt_burst = NULL;
Same is valid for eth_i40e_dev_uninit(), if possible having a separate
function for filter related work.
<...>
^ permalink raw reply
* Re: [PATCH v6 10/17] net/i40e: add flow create function
From: Ferruh Yigit @ 2017-01-05 17:47 UTC (permalink / raw)
To: Beilei Xing, jingjing.wu, helin.zhang; +Cc: dev
In-Reply-To: <1483631170-16681-11-git-send-email-beilei.xing@intel.com>
On 1/5/2017 3:46 PM, Beilei Xing wrote:
> This patch adds i40e_flow_create function to create a
> rule. It will check if a flow matches ethertype filter
> or flow director filter or tunnel filter, if the flow
> matches some kind of filter, then set the filter to HW.
>
> Signed-off-by: Beilei Xing <beilei.xing@intel.com>
> ---
<...>
>
> /*
> + * Struct to store flow created.
> + */
> +struct i40e_flow {
> + TAILQ_ENTRY(i40e_flow) node;
> + enum rte_filter_type filter_type;
> + void *rule;
> +};
It is possible to define this struct as "struct rte_flow", this prevents
repetitive casting between rte_flow and i40e_flow. It is your call.
<...>
^ permalink raw reply
* Re: [PATCH] net/mlx5: fix Tx doorbell
From: Adrien Mazarguil @ 2017-01-05 18:12 UTC (permalink / raw)
To: Ferruh Yigit; +Cc: Nelio Laranjeiro, dev
In-Reply-To: <c9ba6761-20ae-c377-9ae6-3ffbd28b2ae0@intel.com>
On Thu, Jan 05, 2017 at 05:01:27PM +0000, Ferruh Yigit wrote:
> On 1/5/2017 4:52 PM, Adrien Mazarguil wrote:
> > On Thu, Jan 05, 2017 at 05:32:26PM +0100, Adrien Mazarguil wrote:
> >> Hi Ferruh,
> >>
> >> On Thu, Jan 05, 2017 at 03:19:35PM +0000, Ferruh Yigit wrote:
> >>> On 12/9/2016 1:27 PM, Nelio Laranjeiro wrote:
> >>>> Too much data is uselessly written to the Tx doorbell.
> >>>>
> >>>> Fixes: 1d88ba171942 ("net/mlx5: refactor Tx data path")
> >>>>
> >>>> Signed-off-by: Nelio Laranjeiro <nelio.laranjeiro@6wind.com>
> >>>> Acked-by: Adrien Mazarguil <adrien.mazarguil@6wind.com>
> >>>>
> >>>
> >>> Applied to dpdk-next-net/master, thanks.
> >>>
> >>> Is not CC'ing stable intentional, since this patch depends on a patch
> >>> introduced in this release? If not intentional, please CC stable.
> >>
> >> I intended to update the commit message for this patch as in the meantime we
> >> discovered it addresses a significant regression introduced in v16.11.
> >>
> >> CC'ing stable now.
> >>
> >> If possible, can you amend the commit log with:
> >>
> >> ---
> >>
> >> net/mlx5: fix Tx doorbell
> >>
> >> Too much data is uselessly written to the Tx doorbell, which since v16.11
> >> may also cause Tx queues to behave erratically and crash applications.
> >>
> >> This regression was seen on VF devices when the BlueFlame buffer size is
> >> zero (txq->cqe_n == 0) due to the following change:
> >>
> >> - cqe = &(*txq->cqes)[ci & (txq->cqe_n - 1)].cqe64;
> >> + cqe = &(*txq->cqes)[ci & ((1 << txq->cqe_n) - 1)];
> >>
> >> Fixes: 1d88ba171942 ("net/mlx5: refactor Tx data path")
> >> Fixes: e2f116ee3cac ("net/mlx5: reduce memory overhead for CQE handling")
> >>
> >> Signed-off-by: Nelio Laranjeiro <nelio.laranjeiro@6wind.com>
> >> Acked-by: Adrien Mazarguil <adrien.mazarguil@6wind.com>
> >> Cc: stable@dpdk.org
> >>
> >> ---
> >
> > I mixed the commit that introduced the regression with a similar looking yet
> > harmless one, here is the proper message to use, sorry for the noise:
> >
> > ---
> >
> > net/mlx5: fix Tx doorbell
> >
> > Too much data is uselessly written to the Tx doorbell, which since v16.11
> > may also cause Tx queues to behave erratically and crash applications.
> >
> > This regression was seen on VF devices when the BlueFlame buffer size is
> > zero (txq->bf_buf_size) due to the following change:
> >
> > - txq->bf_offset ^= txq->bf_buf_size;
> > + txq->bf_offset ^= (1 << txq->bf_buf_size);
> >
> > Fixes: 1d88ba171942 ("net/mlx5: refactor Tx data path")
> > Fixes: d5793daefec8 ("net/mlx5: reduce memory overhead for BF handling")
> >
> > Signed-off-by: Nelio Laranjeiro <nelio.laranjeiro@6wind.com>
> > Acked-by: Adrien Mazarguil <adrien.mazarguil@6wind.com>
> > Cc: stable@dpdk.org
> >
> > ---
> >
>
> Can you please confirm commit in latest next-net?
Not sure if the "Cc: stable@dpdk.org" line should have been kept, otherwise
it's perfect, thanks Ferruh!
--
Adrien Mazarguil
6WIND
^ permalink raw reply
* Re: [PATCH] net/mlx5: fix Tx doorbell
From: Ferruh Yigit @ 2017-01-05 18:17 UTC (permalink / raw)
To: Adrien Mazarguil; +Cc: Nelio Laranjeiro, dev
In-Reply-To: <20170105181212.GR12822@6wind.com>
On 1/5/2017 6:12 PM, Adrien Mazarguil wrote:
> On Thu, Jan 05, 2017 at 05:01:27PM +0000, Ferruh Yigit wrote:
>> On 1/5/2017 4:52 PM, Adrien Mazarguil wrote:
>>> On Thu, Jan 05, 2017 at 05:32:26PM +0100, Adrien Mazarguil wrote:
>>>> Hi Ferruh,
>>>>
>>>> On Thu, Jan 05, 2017 at 03:19:35PM +0000, Ferruh Yigit wrote:
>>>>> On 12/9/2016 1:27 PM, Nelio Laranjeiro wrote:
>>>>>> Too much data is uselessly written to the Tx doorbell.
>>>>>>
>>>>>> Fixes: 1d88ba171942 ("net/mlx5: refactor Tx data path")
>>>>>>
>>>>>> Signed-off-by: Nelio Laranjeiro <nelio.laranjeiro@6wind.com>
>>>>>> Acked-by: Adrien Mazarguil <adrien.mazarguil@6wind.com>
>>>>>>
>>>>>
>>>>> Applied to dpdk-next-net/master, thanks.
>>>>>
>>>>> Is not CC'ing stable intentional, since this patch depends on a patch
>>>>> introduced in this release? If not intentional, please CC stable.
>>>>
>>>> I intended to update the commit message for this patch as in the meantime we
>>>> discovered it addresses a significant regression introduced in v16.11.
>>>>
>>>> CC'ing stable now.
>>>>
>>>> If possible, can you amend the commit log with:
>>>>
>>>> ---
>>>>
>>>> net/mlx5: fix Tx doorbell
>>>>
>>>> Too much data is uselessly written to the Tx doorbell, which since v16.11
>>>> may also cause Tx queues to behave erratically and crash applications.
>>>>
>>>> This regression was seen on VF devices when the BlueFlame buffer size is
>>>> zero (txq->cqe_n == 0) due to the following change:
>>>>
>>>> - cqe = &(*txq->cqes)[ci & (txq->cqe_n - 1)].cqe64;
>>>> + cqe = &(*txq->cqes)[ci & ((1 << txq->cqe_n) - 1)];
>>>>
>>>> Fixes: 1d88ba171942 ("net/mlx5: refactor Tx data path")
>>>> Fixes: e2f116ee3cac ("net/mlx5: reduce memory overhead for CQE handling")
>>>>
>>>> Signed-off-by: Nelio Laranjeiro <nelio.laranjeiro@6wind.com>
>>>> Acked-by: Adrien Mazarguil <adrien.mazarguil@6wind.com>
>>>> Cc: stable@dpdk.org
>>>>
>>>> ---
>>>
>>> I mixed the commit that introduced the regression with a similar looking yet
>>> harmless one, here is the proper message to use, sorry for the noise:
>>>
>>> ---
>>>
>>> net/mlx5: fix Tx doorbell
>>>
>>> Too much data is uselessly written to the Tx doorbell, which since v16.11
>>> may also cause Tx queues to behave erratically and crash applications.
>>>
>>> This regression was seen on VF devices when the BlueFlame buffer size is
>>> zero (txq->bf_buf_size) due to the following change:
>>>
>>> - txq->bf_offset ^= txq->bf_buf_size;
>>> + txq->bf_offset ^= (1 << txq->bf_buf_size);
>>>
>>> Fixes: 1d88ba171942 ("net/mlx5: refactor Tx data path")
>>> Fixes: d5793daefec8 ("net/mlx5: reduce memory overhead for BF handling")
>>>
>>> Signed-off-by: Nelio Laranjeiro <nelio.laranjeiro@6wind.com>
>>> Acked-by: Adrien Mazarguil <adrien.mazarguil@6wind.com>
>>> Cc: stable@dpdk.org
>>>
>>> ---
>>>
>>
>> Can you please confirm commit in latest next-net?
>
> Not sure if the "Cc: stable@dpdk.org" line should have been kept,
No, we are removing it from the commit.
It is useful in the patch since "git send-email" ensures the stable mail
list is added into CC.
But it is not that useful in the git history.
> otherwise it's perfect, thanks Ferruh!
OK, thanks.
>
^ permalink raw reply
* Re: [PATCH v5 3/8] ethdev: reserve capability flags for PMD-specific API
From: Adrien Mazarguil @ 2017-01-05 18:21 UTC (permalink / raw)
To: Ananyev, Konstantin
Cc: Bie, Tiwei, dev@dpdk.org, Lu, Wenzhuo, Mcnamara, John,
olivier.matz@6wind.com, thomas.monjalon@6wind.com, Zhang, Helin,
Dai, Wei, Wang, Xiao W
In-Reply-To: <2601191342CEEE43887BDE71AB9772583F1006B7@irsmsx105.ger.corp.intel.com>
Hi Konstantin,
On Thu, Jan 05, 2017 at 11:32:38AM +0000, Ananyev, Konstantin wrote:
> Hi Adrien,
>
> >
> > On Thu, Jan 05, 2017 at 07:56:08AM +0800, Tiwei Bie wrote:
> > > On Thu, Jan 05, 2017 at 01:44:18AM +0800, Ananyev, Konstantin wrote:
> > > [...]
> > > > > >
> > > > > > I understand that.
> > > > > > My question was: suppose user would like to create a bonded device over 2 NICs.
> > > > > > One of them is ixgbe, while other would be some other type.
> > > > > > In future get_dev_info() for each of them might return DEV_RX_OFFLOAD_RESERVED_0 bit as set.
> > > > > > But it would mean completely different thing.
> > > > > > How bonded device would know that to deal properly?
> > > > > >
> > > > > > Another example - user has 2 NICs of different type and would like to send the same packet on both of them simultaneously.
> > > > > > As PKT_TX_RESERVED might mean different things for these devices, and user would like to use let say
> > > > > > PKT_TX_IXGBE_MACSEC on one of them, he would need to do a copy of them, instead just increment a refcnt.
> > > > > >
> > > > > > Similar issues might arise at RX handling: user got a packet with PKT_RX_RESERVED_0 set.
> > > > > > What does it really mean if there are different NIC types in the system?
> > > > > > The only way to answer that question, as I can see, is to keep track from what NIC that packet was received.
> > > > > > Which I suppose, is not always convenient.
> > > > > >
> > > > >
> > > > > The main purpose is to put the PMD-specific APIs in a separate
> > > > > namespace instead of mixing the PMD-specific APIs and global APIs
> > > > > up, and also save the bits in mbuf.ol_flags.
> > > > >
> > > > > There are other ways to achieve this goal, such as introducing
> > > > > the PMD specific ol_flags in mbuf second cache line as you said.
> > > > > I just thought defining some reserved bits seems to be the most
> > > > > simple way which won't introduce many changes.
> > > > >
> > > > > What's your suggestions? Should I just revert the changes and
> > > > > define the generic flags directly?
> > > >
> > > > Yes, that would be my preference.
> > > > As I said above - spending extra bit in ol_flags doesn't look like a big problem to me.
> > > > In return there would be no need to consider how to handle all that confusing scenarios in future.
> > >
> > > Okay. I'll update my patches. Thanks a lot for your comments.
> >
> > Well, I do not agree with Konstantin (no one saw this coming eh?)
>
> :)
>
> >and do not think you need to update your series again.
> >
> > PMD-specific symbols have nothing to do in the global namespace in my
> > opinion, they are not versioned and may evolve without notice. Neither
> > applications nor the bonding PMD can rely on them. That's the trade-off.
>
> Not sure I do understand your reasoning.
> For me MACSEC offload is just one of many HW offloads that we support
> and should be treated in exactly the same way.
> Applications should be able to use it in a transparent and reliable way,
> not only under some limited conditions.
> Otherwise what is the point to introduce it at all?
Well my first reply to this thread was asking why isn't the whole API global
from the start then?
Given there are valid reasons for it not to and no plan to make it so in the
near future, applications must be aware that they are including
rte_pmd_ixgbe.h to use it. That in itself is a limiting condition, right?
> Yes, right now it is supported only by ixgbe PMD, but why that should be the
> reason to treat is as second-class citizen?
> Let say PKT_TX_TUNNEL_* offloads also are supported only by one PMD right now.
You are right about PKT_TX_TUNNEL_*, however these flags exist on their own
and are not tied to any API function calls, unlike in this series where
PKT_TX_MACSEC can only be used if the DEV_TX_OFFLOAD_MACSEC_INSERT
capability is present and the whole thing was configured through
rte_pmd_ixgbe_macsec_*() calls after including rte_pmd_ixgbe.h.
To be clear it is not about MACsec per se (as a standardized protocol, I
think related definitions for offloads have their place), but it has to do
with the fact that the rest of the API is PMD-specific and there is a
dependency between them.
> > Therefore until APIs are made global, the safe compromise is to define
> > neutral, reserved symbols that any PMD can use to implement their own
> > temporary APIs for testing purposes. These can be renamed later without
> > changing their value as long as a single PMD uses them.
>
> Ok, so what we'll gain by introducing PKT_TX_RESERVED instead of PKT_TX_MACSEC?
> As I said in my previous mail the redefinition for the same ol_flag bit (and dev capabilities)
> by different PMD might create a lot of confusion in future.
> Does the potential saving of 1 bit really worth it?
That is one benefit, but my point is mainly to keep applications aware that
they are using an API defined by a single PMD, which may be temporary and
whose symbols are not versioned.
Consider this:
rte_mbuf.h:
#define PKT_TX_RESERVED_0 (1 << 42)
rte_pmd_ixgbe.h:
#define PKT_TX_MACSEC PKT_TX_RESERVED_0
That way, applications have to get the PKT_TX_MACSEC definition where the
rest of the API is also defined.
Other PMDs may reuse PKT_TX_RESERVED_0 and other reserved flags to implement
their own experimental APIs.
Applications and the bonding PMD can easily be made aware that such reserved
flags cannot be shared between ports unless they know what the underlying
PMD is, which is already a requirement to use this API in the first place
(for instance, calling rte_pmd_ixgbe_macsec_*() functions with another
vendor's port_id may crash the application).
So the idea if/when the API is made global is to rename PKT_TX_RESERVED_0 to
PKT_TX_MACSEC and keep its original value.
If other PMDs also implemented PKT_TX_RESERVED_0 in the meantime, it is
redefined using a different value. If there is no room left to do so, these
PMDs are out of luck I guess, and their specific API is disabled/removed
until something gets re-designed.
How about this?
--
Adrien Mazarguil
6WIND
^ permalink raw reply
* Re: [dpdk-stable] [PATCH] net/mlx5: fix multi segment packet send
From: Ferruh Yigit @ 2017-01-05 18:55 UTC (permalink / raw)
To: Adrien Mazarguil, Shahaf Shuler; +Cc: dev, stable
In-Reply-To: <20161227102127.GG22106@6wind.com>
On 12/27/2016 10:21 AM, Adrien Mazarguil wrote:
> Hi Shahaf,
>
> On Mon, Dec 26, 2016 at 05:28:36PM +0200, Shahaf Shuler wrote:
>> Dseg pointer is not initialised when the first segment is inlined
>> causing a segmentation fault in such situation.
>>
>> Fixes: 2a66cf378954 ("net/mlx5: support inline send")
>>
>> CC: stable@dpdk.org
>> Signed-off-by: Shahaf Shuler <shahafs@mellanox.com>
...
> Acked-by: Adrien Mazarguil <adrien.mazarguil@6wind.com>
Applied to dpdk-next-net/master, thanks.
(whitespace int the comment fixed)
^ permalink raw reply
* [PATCH] pmdinfogen: Resolve coverity scan forward null issue
From: Neil Horman @ 2017-01-05 19:22 UTC (permalink / raw)
To: dev; +Cc: Neil Horman, Neil Horman, john.mcnamara, thomas.monjalon
From: Neil Horman <nhorman@redhat.com>
Coverity issue 139593 reports a forward null dereference from a for loop
that works with a variable previously tested for null that had no error
handling or condition to prevent it. Pretty obvious fix below.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
CC: john.mcnamara@intel.com
CC: thomas.monjalon@6wind.com
---
buildtools/pmdinfogen/pmdinfogen.c | 15 ++++++++-------
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/buildtools/pmdinfogen/pmdinfogen.c b/buildtools/pmdinfogen/pmdinfogen.c
index 5129c57..ba1a12e 100644
--- a/buildtools/pmdinfogen/pmdinfogen.c
+++ b/buildtools/pmdinfogen/pmdinfogen.c
@@ -226,13 +226,14 @@ static int parse_elf(struct elf_info *info, const char *filename)
}
if (!info->symtab_start)
fprintf(stderr, "%s has no symtab?\n", filename);
-
- /* Fix endianness in symbols */
- for (sym = info->symtab_start; sym < info->symtab_stop; sym++) {
- sym->st_shndx = TO_NATIVE(endian, 16, sym->st_shndx);
- sym->st_name = TO_NATIVE(endian, 32, sym->st_name);
- sym->st_value = TO_NATIVE(endian, ADDR_SIZE, sym->st_value);
- sym->st_size = TO_NATIVE(endian, ADDR_SIZE, sym->st_size);
+ else {
+ /* Fix endianness in symbols */
+ for (sym = info->symtab_start; sym < info->symtab_stop; sym++) {
+ sym->st_shndx = TO_NATIVE(endian, 16, sym->st_shndx);
+ sym->st_name = TO_NATIVE(endian, 32, sym->st_name);
+ sym->st_value = TO_NATIVE(endian, ADDR_SIZE, sym->st_value);
+ sym->st_size = TO_NATIVE(endian, ADDR_SIZE, sym->st_size);
+ }
}
if (symtab_shndx_idx != ~0U) {
--
2.9.3
^ permalink raw reply related
* Re: [PATCH v2] net/mlx5: add support for ConnectX-5 NICs
From: Adrien Mazarguil @ 2017-01-05 20:26 UTC (permalink / raw)
To: Yongseok Koh; +Cc: ferruh.yigit, dev
In-Reply-To: <20170105115254.27401-1-yskoh@mellanox.com>
Hi Koh,
A few remaining comments, please see below.
On Thu, Jan 05, 2017 at 03:52:54AM -0800, Yongseok Koh wrote:
> Add PCI device ID for ConnectX-5 and enable multi-packet send for PF and VF
> along with changing documentation and release note.
>
> Signed-off-by: Yongseok Koh <yskoh@mellanox.com>
> ---
>
> ConnectX-5 is a newly announced NIC of Mellanox. This patch includes basic
> enablement of ConnectX-5 as well as documentation.
>
> config/common_base | 2 +-
> doc/guides/nics/mlx5.rst | 37 +++++++++++++++++-------------
> doc/guides/rel_notes/release_17_02.rst | 5 ++++
> drivers/net/mlx5/mlx5.c | 42 ++++++++++++++++++++++++++++++----
> drivers/net/mlx5/mlx5.h | 4 ++++
> drivers/net/mlx5/mlx5_ethdev.c | 7 ++----
> drivers/net/mlx5/mlx5_txq.c | 2 +-
> 7 files changed, 71 insertions(+), 28 deletions(-)
[...]
> diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
[...]
> @@ -185,8 +185,8 @@ Run-time configuration
> save PCI bandwidth and improve performance at the cost of a slightly
> higher CPU usage.
>
> - It is currently only supported on the ConnectX-4 Lx family of adapters.
> - Enabled by default.
> + It is currently only supported on the ConnectX-4 Lx and ConnectX-5
> + families of adapters. Enabled by default.
Minor nit, can you remove the double spacing here? I know there is another
one in the same document but it does break the style, it will be fixed
eventually.
[...]
> @@ -241,12 +242,16 @@ DPDK and must be installed separately:
>
> Currently supported by DPDK:
>
> -- Mellanox OFED **3.4-1.0.0.0**.
> +- Mellanox OFED version:
An empty line is missing after this line. It causes the list to not display
properly once exported to other formats.
> + - ConnectX-4: **3.4-1.0.0.0** or higher
> + - ConnectX-4 Lx: **3.4-1.0.0.0** or higher
> + - ConnectX-5: **4.0-0.0.8.1** or higher
>
> - firmware version:
>
> - - ConnectX-4: **12.17.1010**
> - - ConnectX-4 Lx: **14.17.1010**
> + - ConnectX-4: **12.17.1010** or higher
> + - ConnectX-4 Lx: **14.17.1010** or higher
> + - ConnectX-5: **16.18.0296** or higher
"or higher" was implicit until now, if you want to make it explicit I think
it's better to write it once in some other place (e.g. by clarifying
"Currently supported by DPDK"). Falls outside the scope of this patch
though.
> Getting Mellanox OFED
> ~~~~~~~~~~~~~~~~~~~~~
> @@ -288,8 +293,8 @@ behavior as librte_pmd_mlx4:
> Usage example
> -------------
>
> -This section demonstrates how to launch **testpmd** with Mellanox ConnectX-4
> -devices managed by librte_pmd_mlx5.
> +This section demonstrates how to launch **testpmd** with Mellanox
> +ConnectX-4/ConnectX-5 devices managed by librte_pmd_mlx5.
>
> #. Load the kernel modules:
>
> diff --git a/doc/guides/rel_notes/release_17_02.rst b/doc/guides/rel_notes/release_17_02.rst
> index 699487dfe..6da4d0f8d 100644
> --- a/doc/guides/rel_notes/release_17_02.rst
> +++ b/doc/guides/rel_notes/release_17_02.rst
> @@ -61,6 +61,11 @@ New Features
> A new network PMD which supports Solarflare SFN7xxx and SFN8xxx family
> of 10/40 Gbps adapters has been added.
>
> +* **Added support for Mellanox ConnectX-5 adpaters (mlx5).**
Typo, "adpaters".
--
Adrien Mazarguil
6WIND
^ permalink raw reply
* Re: [dpdk-stable] [PATCH 1/5] net/qede: fix scatter-gather issue
From: Harish Patil @ 2017-01-05 21:12 UTC (permalink / raw)
To: Ferruh Yigit, Mody, Rasesh, dev@dpdk.org
Cc: stable@dpdk.org, Dept-Eng DPDK Dev
In-Reply-To: <787fc8d8-1003-d2c0-e8e1-a2b915517456@intel.com>
>
>On 12/31/2016 8:16 AM, Rasesh Mody wrote:
>> From: Harish Patil <harish.patil@qlogic.com>
>>
>> - Make qede_process_sg_pkts() inline and add unlikely check
>> - Fix mbuf segment chaining logic in qede_process_sg_pkts()
>> - Change qede_encode_sg_bd() to return total segments required
>> - Fix first TX buffer descriptor's length
>> - Replace repeatitive code using a macro
>>
>> Fixes: bec0228816c0 ("net/qede: support scatter gather")
>>
>> Signed-off-by: Harish Patil <harish.patil@qlogic.com>
>> ---
>
>Hi Harish,
>
>This patch doesn't apply cleanly on top next-net, after pci_dev changes
>rebased into next-net tree.
>
>Can you please send the new version of the patchset rebased on top of
>latest next-net?
>
>Thanks,
>ferruh
>
><...>
>
Hi Ferruh,
Sure will do that.
Thanks,
Harish
^ permalink raw reply
* [PATCH] doc: fix a typo in proc_info guide.
From: Rami Rosen @ 2017-01-05 21:36 UTC (permalink / raw)
To: dev; +Cc: Rami Rosen
This patch fixes a typo in proc_info guide (tools),
doc/guides/tools/proc_info.rst.
Signed-off-by: Rami Rosen <rami.rosen@intel.com>
---
doc/guides/tools/proc_info.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/guides/tools/proc_info.rst b/doc/guides/tools/proc_info.rst
index baaf977..fd17e27 100644
--- a/doc/guides/tools/proc_info.rst
+++ b/doc/guides/tools/proc_info.rst
@@ -56,7 +56,7 @@ The stats parameter controls the printing of generic port statistics. If no
port mask is specified stats are printed for all DPDK ports.
**--xstats**
-The stats parameter controls the printing of extended port statistics. If no
+The xstats parameter controls the printing of extended port statistics. If no
port mask is specified xstats are printed for all DPDK ports.
**--stats-reset**
--
1.9.1
^ permalink raw reply related
* Re: [dpdk-stable] [PATCH 1/5] net/qede: fix scatter-gather issue
From: Mody, Rasesh @ 2017-01-05 22:35 UTC (permalink / raw)
To: Harish Patil, Ferruh Yigit, dev@dpdk.org
Cc: stable@dpdk.org, Dept-Eng DPDK Dev
In-Reply-To: <D493F692.C58EC%Harish.Patil@cavium.com>
> From: Harish Patil [mailto:harish.patil@qlogic.com]
> Sent: Thursday, January 05, 2017 1:12 PM
>
> >
> >On 12/31/2016 8:16 AM, Rasesh Mody wrote:
> >> From: Harish Patil <harish.patil@qlogic.com>
> >>
> >> - Make qede_process_sg_pkts() inline and add unlikely check
> >> - Fix mbuf segment chaining logic in qede_process_sg_pkts()
> >> - Change qede_encode_sg_bd() to return total segments required
> >> - Fix first TX buffer descriptor's length
> >> - Replace repeatitive code using a macro
> >>
> >> Fixes: bec0228816c0 ("net/qede: support scatter gather")
> >>
> >> Signed-off-by: Harish Patil <harish.patil@qlogic.com>
> >> ---
> >
> >Hi Harish,
> >
> >This patch doesn't apply cleanly on top next-net, after pci_dev changes
> >rebased into next-net tree.
We are not seeing failure when applying [PATCH 1/5] net/qede: fix scatter-gather issue on latest dpdk-next-net. However, we do see a failure when trying to apply [PATCH 2/5] net/qede: fix minimum buffer size and scatter Rx check due to pci_dev changes rebased into next-net tree. We'll submit a v2 series rebased on latest next-net.
Thanks!
-Rasesh
^ permalink raw reply
* Re: [PATCH v2 1/5] eal: Set numa node value for system which not support NUMA.
From: Yong Wang @ 2017-01-06 0:01 UTC (permalink / raw)
To: Ferruh Yigit, nickcooper-zhangtonghao, dev@dpdk.org
In-Reply-To: <8cb35df0-cdd6-143c-4f78-379a89f44616@intel.com>
> -----Original Message-----
> From: Ferruh Yigit [mailto:ferruh.yigit@intel.com]
> Sent: Thursday, January 5, 2017 6:24 AM
> To: nickcooper-zhangtonghao <nic@opencloud.tech>; dev@dpdk.org; Yong
> Wang <yongwang@vmware.com>
> Subject: Re: [dpdk-dev] [PATCH v2 1/5] eal: Set numa node value for system
> which not support NUMA.
>
> On 1/5/2017 12:01 PM, nickcooper-zhangtonghao wrote:
> > The NUMA node information for PCI devices provided through
> > sysfs is invalid for AMD Opteron(TM) Processor 62xx and 63xx
> > on Red Hat Enterprise Linux 6, and VMs on some hypervisors.
> >
> > Signed-off-by: nickcooper-zhangtonghao <nic@opencloud.tech>
>
> Hi nickcooper-zhangtonghao,
>
> The patches in the patchset are individual patches, right? Is there any
> dependency between them?
>
> And CC'ed vmxnet3 driver maintainer: Yong Wang <yongwang@vmware.com>
Can you add the exact steps to reproduce the vmxnet3 issues to help the review and the verification. My guess is that you have stopped the device, changed some ring parameters (to something larger than the previous settings) and restarted the device. Such info should be included into the commit description in addition to just saying what the patch does.
> Thanks,
> ferruh
>
> > ---
> > lib/librte_eal/linuxapp/eal/eal_pci.c | 8 +++++++-
> > 1 file changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/lib/librte_eal/linuxapp/eal/eal_pci.c
> b/lib/librte_eal/linuxapp/eal/eal_pci.c
> > index 4350134..5dfdbe9 100644
> > --- a/lib/librte_eal/linuxapp/eal/eal_pci.c
> > +++ b/lib/librte_eal/linuxapp/eal/eal_pci.c
> > @@ -317,7 +317,13 @@
> > free(dev);
> > return -1;
> > }
> > - dev->device.numa_node = tmp;
> > + /* The NUMA node information for PCI devices provided
> through
> > + * sysfs is invalid for AMD Opteron(TM) Processor 62xx and
> 63xx
> > + * on Red Hat Enterprise Linux 6, and VMs on some
> hypervisors.
> > + * In the upstream linux kernel, the numa_node is an integer,
> > + * which data type is int, not unsigned long.
> > + */
> > + dev->device.numa_node = (int)tmp > 0 ? (int)tmp : 0;
> > }
> >
> > /* parse resources */
> >
^ permalink raw reply
* Re: [PATCH v7 06/27] net/i40e: set VF unicast promisc mode from PF
From: Wu, Jingjing @ 2017-01-06 0:32 UTC (permalink / raw)
To: Lu, Wenzhuo, dev@dpdk.org; +Cc: Lu, Wenzhuo
In-Reply-To: <1483426488-117332-7-git-send-email-wenzhuo.lu@intel.com>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Wenzhuo Lu
> Sent: Tuesday, January 3, 2017 2:54 PM
> To: dev@dpdk.org
> Cc: Lu, Wenzhuo <wenzhuo.lu@intel.com>
> Subject: [dpdk-dev] [PATCH v7 06/27] net/i40e: set VF unicast promisc mode
> from PF
>
> Support enabling/disabling VF unicast promiscuous mode from PF.
> User can call the API on PF to enable/disable a specific VF's unicast promiscuous
> mode.
>
> Signed-off-by: Wenzhuo Lu <wenzhuo.lu@intel.com>
> ---
> drivers/net/i40e/i40e_ethdev.c | 39
> +++++++++++++++++++++++++++++++
> drivers/net/i40e/rte_pmd_i40e.h | 19 +++++++++++++++
> drivers/net/i40e/rte_pmd_i40e_version.map | 1 +
> 3 files changed, 59 insertions(+)
>
> diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
> index a5d6d05..3d7ee03 100644
> --- a/drivers/net/i40e/i40e_ethdev.c
> +++ b/drivers/net/i40e/i40e_ethdev.c
> @@ -10120,3 +10120,42 @@ static void i40e_set_default_mac_addr(struct
> rte_eth_dev *dev,
>
> return ret;
> }
> +
> +int
> +rte_pmd_i40e_set_vf_unicast_promisc(uint8_t port, uint16_t vf_id,
> +uint8_t on) {
> + struct rte_eth_dev *dev;
> + struct rte_eth_dev_info dev_info;
> + struct i40e_pf *pf;
> + struct i40e_vsi *vsi;
> + struct i40e_hw *hw;
> + int ret;
> +
> + RTE_ETH_VALID_PORTID_OR_ERR_RET(port, -ENODEV);
> +
> + dev = &rte_eth_devices[port];
> + rte_eth_dev_info_get(port, &dev_info);
> +
> + if (vf_id >= dev_info.max_vfs)
> + return -EINVAL;
> +
> + pf = I40E_DEV_PRIVATE_TO_PF(dev->data->dev_private);
> +
> + if (vf_id > pf->vf_num - 1 || !pf->vfs) {
> + PMD_DRV_LOG(ERR, "Invalid argument.");
> + return -EINVAL;
> + }
Same comments as previous patches.
> + vsi = pf->vfs[vf_id].vsi;
> + if (!vsi)
> + return -EINVAL;
> +
> + hw = I40E_VSI_TO_HW(vsi);
> +
> + ret = i40e_aq_set_vsi_unicast_promiscuous(hw, vsi->seid,
> + on, NULL, true);
> + if (ret != I40E_SUCCESS)
> + PMD_DRV_LOG(ERR, "Failed to set unicast promiscuous mode");
> +
> + return ret;
ret is the error code defined in i40e driver, please use the error code in eth dev lib.
Thanks
Jingjing
^ permalink raw reply
* Re: [PATCH v7 05/27] net/i40e: set Tx loopback from PF
From: Wu, Jingjing @ 2017-01-06 0:32 UTC (permalink / raw)
To: Lu, Wenzhuo, dev@dpdk.org; +Cc: Lu, Wenzhuo
In-Reply-To: <1483426488-117332-6-git-send-email-wenzhuo.lu@intel.com>
Is the Tx lookback meaning as VEB mode ore VEPA mode?
If so, how about change the API's name to set_switch_mode?
Another comment is: you removed all mac vlan filters before changing
The mode, and restore them after changing. How about vlan filters? The
Patch for vlan anti-spoof enables it, correct?
Thanks
JIngjing
^ permalink raw reply
* Re: [PATCH v7 10/27] net/i40e: set VF MAC from PF support
From: Wu, Jingjing @ 2017-01-06 0:32 UTC (permalink / raw)
To: Lu, Wenzhuo, dev@dpdk.org; +Cc: Yigit, Ferruh
In-Reply-To: <1483426488-117332-11-git-send-email-wenzhuo.lu@intel.com>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Wenzhuo Lu
> Sent: Tuesday, January 3, 2017 2:55 PM
> To: dev@dpdk.org
> Cc: Yigit, Ferruh <ferruh.yigit@intel.com>
> Subject: [dpdk-dev] [PATCH v7 10/27] net/i40e: set VF MAC from PF support
>
> From: Ferruh Yigit <ferruh.yigit@intel.com>
>
> Support setting VF MAC address from PF.
> User can call the API on PF to set a specific VF's MAC address.
>
> This will remove all existing MAC filters.
>
> Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
> ---
> drivers/net/i40e/i40e_ethdev.c | 42
> +++++++++++++++++++++++++++++++
> drivers/net/i40e/rte_pmd_i40e.h | 19 ++++++++++++++
> drivers/net/i40e/rte_pmd_i40e_version.map | 1 +
> 3 files changed, 62 insertions(+)
>
> diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
> index 9d050c8..758b574 100644
> --- a/drivers/net/i40e/i40e_ethdev.c
> +++ b/drivers/net/i40e/i40e_ethdev.c
> @@ -10198,3 +10198,45 @@ static void i40e_set_default_mac_addr(struct
> rte_eth_dev *dev,
>
> return ret;
> }
> +
> +int
> +rte_pmd_i40e_set_vf_mac_addr(uint8_t port, uint16_t vf_id,
> + struct ether_addr *mac_addr)
> +{
> + struct rte_eth_dev_info dev_info;
> + struct i40e_mac_filter *f;
> + struct rte_eth_dev *dev;
> + struct i40e_pf_vf *vf;
> + struct i40e_vsi *vsi;
> + struct i40e_pf *pf;
> + void *temp;
> +
> + if (i40e_validate_mac_addr((u8 *)mac_addr) != I40E_SUCCESS)
> + return -EINVAL;
> +
> + RTE_ETH_VALID_PORTID_OR_ERR_RET(port, -ENODEV);
> +
> + dev = &rte_eth_devices[port];
> + rte_eth_dev_info_get(port, &dev_info);
> +
> + if (vf_id >= dev_info.max_vfs)
> + return -EINVAL;
> +
> + pf = I40E_DEV_PRIVATE_TO_PF(dev->data->dev_private);
> +
> + if (vf_id > pf->vf_num - 1 || !pf->vfs)
> + return -EINVAL;
> +
> + vf = &pf->vfs[vf_id];
> + vsi = vf->vsi;
> + if (!vsi)
> + return -EINVAL;
> +
> + ether_addr_copy(mac_addr, &vf->mac_addr);
Only store the mac address in vf struct?
Are you supposing the API is called before VF is initialized? If so, it's better to comment it.
Thanks
Jingjing
^ permalink raw reply
* Re: [PATCH v7 03/27] net/i40e: set VF MAC anti-spoofing from PF
From: Wu, Jingjing @ 2017-01-06 0:33 UTC (permalink / raw)
To: Lu, Wenzhuo, dev@dpdk.org; +Cc: Lu, Wenzhuo
In-Reply-To: <1483426488-117332-4-git-send-email-wenzhuo.lu@intel.com>
> +
> + vsi->info.valid_sections =
> cpu_to_le16(I40E_AQ_VSI_PROP_SECURITY_VALID);
> + if (on)
> + vsi->info.sec_flags |=
> I40E_AQ_VSI_SEC_FLAG_ENABLE_MAC_CHK;
> + else
> + vsi->info.sec_flags &=
> ~I40E_AQ_VSI_SEC_FLAG_ENABLE_MAC_CHK;
> +
> + memset(&ctxt, 0, sizeof(ctxt));
> + (void)rte_memcpy(&ctxt.info, &vsi->info, sizeof(vsi->info));
> + ctxt.seid = vsi->seid;
> +
> + hw = I40E_VSI_TO_HW(vsi);
> + ret = i40e_aq_update_vsi_params(hw, &ctxt, NULL);
> + if (ret != I40E_SUCCESS)
> + PMD_DRV_LOG(ERR, "Failed to update VSI params");
If fails, will you revert the info in vsi struct?
> +
> + return ret;
Please return eth dev lib error code, but not I40E_XXX
^ permalink raw reply
* Re: [PATCH v7 14/27] net/i40e: set VF VLAN insertion from PF
From: Wu, Jingjing @ 2017-01-06 0:33 UTC (permalink / raw)
To: Lu, Wenzhuo, dev@dpdk.org; +Cc: Iremonger, Bernard
In-Reply-To: <1483426488-117332-15-git-send-email-wenzhuo.lu@intel.com>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Wenzhuo Lu
> Sent: Tuesday, January 3, 2017 2:55 PM
> To: dev@dpdk.org
> Cc: Iremonger, Bernard <bernard.iremonger@intel.com>
> Subject: [dpdk-dev] [PATCH v7 14/27] net/i40e: set VF VLAN insertion from PF
>
> From: Bernard Iremonger <bernard.iremonger@intel.com>
>
> Support inserting VF VLAN id from PF.
> User can call the API on PF to insert a VLAN id to a specific VF.
>
> Signed-off-by: Bernard Iremonger <bernard.iremonger@intel.com>
> ---
> drivers/net/i40e/i40e_ethdev.c | 56
> +++++++++++++++++++++++++++++++
> drivers/net/i40e/rte_pmd_i40e.h | 19 +++++++++++
> drivers/net/i40e/rte_pmd_i40e_version.map | 1 +
> 3 files changed, 76 insertions(+)
>
> diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
> index 7ab1c93..31c387d 100644
> --- a/drivers/net/i40e/i40e_ethdev.c
> +++ b/drivers/net/i40e/i40e_ethdev.c
> @@ -10266,3 +10266,59 @@ static void i40e_set_default_mac_addr(struct
> rte_eth_dev *dev,
> else
> return -EINVAL;
> }
> +
> +int rte_pmd_i40e_set_vf_vlan_insert(uint8_t port, uint16_t vf_id,
> + uint16_t vlan_id)
> +{
> + struct rte_eth_dev *dev;
> + struct rte_eth_dev_info dev_info;
> + struct i40e_pf *pf;
> + struct i40e_hw *hw;
> + struct i40e_vsi *vsi;
> + struct i40e_vsi_context ctxt;
> + int ret;
> +
> + RTE_ETH_VALID_PORTID_OR_ERR_RET(port, -ENODEV);
> +
> + dev = &rte_eth_devices[port];
> + rte_eth_dev_info_get(port, &dev_info);
It looks dev_info is not used in this function.
> + pf = I40E_DEV_PRIVATE_TO_PF(dev->data->dev_private);
> + hw = I40E_PF_TO_HW(pf);
> +
> + /**
> + * return -ENODEV if SRIOV not enabled, VF number not configured
> + * or no queue assigned.
> + */
> + if (!hw->func_caps.sr_iov_1_1 || pf->vf_num == 0 ||
> + pf->vf_nb_qps == 0)
> + return -ENODEV;
> +
> + if (vf_id >= pf->vf_num || !pf->vfs)
> + return -EINVAL;
> +
> + if (vlan_id > ETHER_MAX_VLAN_ID)
> + return -EINVAL;
> +
> + vsi = pf->vfs[vf_id].vsi;
> + if (!vsi)
> + return -EINVAL;
> +
> + vsi->info.valid_sections =
> cpu_to_le16(I40E_AQ_VSI_PROP_VLAN_VALID);
> + vsi->info.pvid = vlan_id;
> + if (vlan_id > 0)
> + vsi->info.port_vlan_flags |= I40E_AQ_VSI_PVLAN_INSERT_PVID;
> + else
> + vsi->info.port_vlan_flags &=
> ~I40E_AQ_VSI_PVLAN_INSERT_PVID;
So, Pvid is used here for insert. Does it has any relationship with vlan anti-spoof patch?
If so, it's better to consider how to deal with that.
Thanks
Jingjing
^ permalink raw reply
* Re: [PATCH v7 17/27] net/i40e: set VF VLAN filter from PF
From: Wu, Jingjing @ 2017-01-06 0:36 UTC (permalink / raw)
To: Lu, Wenzhuo, dev@dpdk.org; +Cc: Iremonger, Bernard
In-Reply-To: <1483426488-117332-18-git-send-email-wenzhuo.lu@intel.com>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Wenzhuo Lu
> Sent: Tuesday, January 3, 2017 2:55 PM
> To: dev@dpdk.org
> Cc: Iremonger, Bernard <bernard.iremonger@intel.com>
> Subject: [dpdk-dev] [PATCH v7 17/27] net/i40e: set VF VLAN filter from PF
>
> From: Bernard Iremonger <bernard.iremonger@intel.com>
>
> add rte_pmd_i40e_set_vf_vlan_filter API.
> User can call the API on PF to enable/disable a set of VF's VLAN filters.
>
> Signed-off-by: Bernard Iremonger <bernard.iremonger@intel.com>
> ---
> drivers/net/i40e/i40e_ethdev.c | 52
> +++++++++++++++++++++++++++++++
> drivers/net/i40e/rte_pmd_i40e.h | 22 +++++++++++++
> drivers/net/i40e/rte_pmd_i40e_version.map | 1 +
> 3 files changed, 75 insertions(+)
>
> diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
> index 4d2fb20..47e03d6 100644
> --- a/drivers/net/i40e/i40e_ethdev.c
> +++ b/drivers/net/i40e/i40e_ethdev.c
> @@ -10428,3 +10428,55 @@ int rte_pmd_i40e_set_vf_vlan_tag(uint8_t port,
> uint16_t vf_id, uint8_t on)
>
> return ret;
> }
> +
> +int rte_pmd_i40e_set_vf_vlan_filter(uint8_t port, uint16_t vlan_id,
> + uint64_t vf_mask, uint8_t on)
> +{
> + struct rte_eth_dev *dev;
> + struct rte_eth_dev_info dev_info;
> + struct i40e_pf *pf;
> + uint16_t pool_idx;
> + int ret = I40E_SUCCESS;
> +
> + RTE_ETH_VALID_PORTID_OR_ERR_RET(port, -ENODEV);
> +
> + dev = &rte_eth_devices[port];
> + rte_eth_dev_info_get(port, &dev_info);
> +
> + if (vlan_id > ETHER_MAX_VLAN_ID)
> + return -EINVAL;
> +
> + if (on > 1)
> + return -EINVAL;
> +
> + pf = I40E_DEV_PRIVATE_TO_PF(dev->data->dev_private);
> + if ((pf->flags & I40E_FLAG_VMDQ) == 0) {
> + PMD_INIT_LOG(ERR, "Firmware doesn't support VMDQ");
> + return -ENOTSUP;
> + }
> +
> + if (!pf->vmdq) {
> + PMD_INIT_LOG(INFO, "VMDQ not configured");
> + return -ENOTSUP;
> + }
> +
> + for (pool_idx = 0;
> + pool_idx < ETH_64_POOLS &&
> + pool_idx < pf->nb_cfg_vmdq_vsi &&
> + ret == I40E_SUCCESS;
> + pool_idx++) {
> + if (vf_mask & ((uint64_t)(1ULL << pool_idx))) {
> + if (on)
> + ret = i40e_vsi_add_vlan(pf->vmdq[pool_idx].vsi,
> + vlan_id);
> + else
> + ret = i40e_vsi_delete_vlan(
> + pf->vmdq[pool_idx].vsi, vlan_id);
> + }
> + }
The head is saying "set VF VLAN filter", why do you deal with VMDQ VSIs?
^ permalink raw reply
* [PATCH v3] net/mlx5: add support for ConnectX-5 NICs
From: Yongseok Koh @ 2017-01-06 0:49 UTC (permalink / raw)
To: ferruh.yigit; +Cc: dev, adrien.mazarguil, Yongseok Koh
In-Reply-To: <20170105023219.10146-1-yskoh@mellanox.com>
Add PCI device ID for ConnectX-5 and enable multi-packet send for PF and VF
along with changing documentation and release note.
Signed-off-by: Yongseok Koh <yskoh@mellanox.com>
---
ConnectX-5 is a newly announced NIC of Mellanox. This patch includes basic
enablement of ConnectX-5 as well as documentation.
config/common_base | 2 +-
doc/guides/nics/mlx5.rst | 34 +++++++++++++++------------
doc/guides/rel_notes/release_17_02.rst | 5 ++++
drivers/net/mlx5/mlx5.c | 42 ++++++++++++++++++++++++++++++----
drivers/net/mlx5/mlx5.h | 4 ++++
drivers/net/mlx5/mlx5_ethdev.c | 7 ++----
drivers/net/mlx5/mlx5_txq.c | 2 +-
7 files changed, 70 insertions(+), 26 deletions(-)
diff --git a/config/common_base b/config/common_base
index faee944c8..bb7beacf6 100644
--- a/config/common_base
+++ b/config/common_base
@@ -204,7 +204,7 @@ CONFIG_RTE_LIBRTE_MLX4_TX_MP_CACHE=8
CONFIG_RTE_LIBRTE_MLX4_SOFT_COUNTERS=1
#
-# Compile burst-oriented Mellanox ConnectX-4 (MLX5) PMD
+# Compile burst-oriented Mellanox ConnectX-4 & ConnectX-5 (MLX5) PMD
#
CONFIG_RTE_LIBRTE_MLX5_PMD=n
CONFIG_RTE_LIBRTE_MLX5_DEBUG=n
diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
index 98d134190..a41c4327c 100644
--- a/doc/guides/nics/mlx5.rst
+++ b/doc/guides/nics/mlx5.rst
@@ -30,10 +30,10 @@
MLX5 poll mode driver
=====================
-The MLX5 poll mode driver library (**librte_pmd_mlx5**) provides support for
-**Mellanox ConnectX-4** and **Mellanox ConnectX-4 Lx** families of
-10/25/40/50/100 Gb/s adapters as well as their virtual functions (VF) in
-SR-IOV context.
+The MLX5 poll mode driver library (**librte_pmd_mlx5**) provides support
+for **Mellanox ConnectX-4**, **Mellanox ConnectX-4 Lx** and **Mellanox
+ConnectX-5** families of 10/25/40/50/100 Gb/s adapters as well as their
+virtual functions (VF) in SR-IOV context.
Information and documentation about these adapters can be found on the
`Mellanox website <http://www.mellanox.com>`__. Help is also provided by the
@@ -185,8 +185,8 @@ Run-time configuration
save PCI bandwidth and improve performance at the cost of a slightly
higher CPU usage.
- It is currently only supported on the ConnectX-4 Lx family of adapters.
- Enabled by default.
+ It is currently only supported on the ConnectX-4 Lx and ConnectX-5
+ families of adapters. Enabled by default.
Prerequisites
-------------
@@ -207,8 +207,8 @@ DPDK and must be installed separately:
- **libmlx5**
- Low-level user space driver library for Mellanox ConnectX-4 devices,
- it is automatically loaded by libibverbs.
+ Low-level user space driver library for Mellanox ConnectX-4/ConnectX-5
+ devices, it is automatically loaded by libibverbs.
This library basically implements send/receive calls to the hardware
queues.
@@ -222,14 +222,15 @@ DPDK and must be installed separately:
Unlike most other PMDs, these modules must remain loaded and bound to
their devices:
- - mlx5_core: hardware driver managing Mellanox ConnectX-4 devices and
- related Ethernet kernel network devices.
+ - mlx5_core: hardware driver managing Mellanox ConnectX-4/ConnectX-5
+ devices and related Ethernet kernel network devices.
- mlx5_ib: InifiniBand device driver.
- ib_uverbs: user space driver for Verbs (entry point for libibverbs).
- **Firmware update**
- Mellanox OFED releases include firmware updates for ConnectX-4 adapters.
+ Mellanox OFED releases include firmware updates for ConnectX-4/ConnectX-5
+ adapters.
Because each release provides new features, these updates must be applied to
match the kernel modules and libraries they come with.
@@ -241,12 +242,17 @@ DPDK and must be installed separately:
Currently supported by DPDK:
-- Mellanox OFED **3.4-1.0.0.0**.
+- Mellanox OFED version:
+
+ - ConnectX-4: **3.4-1.0.0.0**
+ - ConnectX-4 Lx: **3.4-1.0.0.0**
+ - ConnectX-5: **4.0-0.0.8.1**
- firmware version:
- ConnectX-4: **12.17.1010**
- ConnectX-4 Lx: **14.17.1010**
+ - ConnectX-5: **16.18.0296**
Getting Mellanox OFED
~~~~~~~~~~~~~~~~~~~~~
@@ -288,8 +294,8 @@ behavior as librte_pmd_mlx4:
Usage example
-------------
-This section demonstrates how to launch **testpmd** with Mellanox ConnectX-4
-devices managed by librte_pmd_mlx5.
+This section demonstrates how to launch **testpmd** with Mellanox
+ConnectX-4/ConnectX-5 devices managed by librte_pmd_mlx5.
#. Load the kernel modules:
diff --git a/doc/guides/rel_notes/release_17_02.rst b/doc/guides/rel_notes/release_17_02.rst
index 699487dfe..5762d3f51 100644
--- a/doc/guides/rel_notes/release_17_02.rst
+++ b/doc/guides/rel_notes/release_17_02.rst
@@ -61,6 +61,11 @@ New Features
A new network PMD which supports Solarflare SFN7xxx and SFN8xxx family
of 10/40 Gbps adapters has been added.
+* **Added support for Mellanox ConnectX-5 adapters (mlx5).**
+
+ Support for Mellanox ConnectX-5 family of 10/25/40/50/100 Gbps adapters
+ has been added to the existing mlx5 PMD.
+
Resolved Issues
---------------
diff --git a/drivers/net/mlx5/mlx5.c b/drivers/net/mlx5/mlx5.c
index b97b6d16a..6293c1fda 100644
--- a/drivers/net/mlx5/mlx5.c
+++ b/drivers/net/mlx5/mlx5.c
@@ -286,7 +286,7 @@ mlx5_args_check(const char *key, const char *val, void *opaque)
} else if (strcmp(MLX5_TXQS_MIN_INLINE, key) == 0) {
priv->txqs_inline = tmp;
} else if (strcmp(MLX5_TXQ_MPW_EN, key) == 0) {
- priv->mps = !!tmp;
+ priv->mps &= !!tmp; /* Enable MPW only if HW supports */
} else {
WARN("%s: unknown parameter", key);
return -EINVAL;
@@ -408,10 +408,26 @@ mlx5_pci_probe(struct rte_pci_driver *pci_drv, struct rte_pci_device *pci_dev)
sriov = ((pci_dev->id.device_id ==
PCI_DEVICE_ID_MELLANOX_CONNECTX4VF) ||
(pci_dev->id.device_id ==
- PCI_DEVICE_ID_MELLANOX_CONNECTX4LXVF));
- /* Multi-packet send is only supported by ConnectX-4 Lx PF. */
- mps = (pci_dev->id.device_id ==
- PCI_DEVICE_ID_MELLANOX_CONNECTX4LX);
+ PCI_DEVICE_ID_MELLANOX_CONNECTX4LXVF) ||
+ (pci_dev->id.device_id ==
+ PCI_DEVICE_ID_MELLANOX_CONNECTX5VF) ||
+ (pci_dev->id.device_id ==
+ PCI_DEVICE_ID_MELLANOX_CONNECTX5EXVF));
+ /*
+ * Multi-packet send is supported by ConnectX-4 Lx PF as well
+ * as all ConnectX-5 devices.
+ */
+ switch (pci_dev->id.device_id) {
+ case PCI_DEVICE_ID_MELLANOX_CONNECTX4LX:
+ case PCI_DEVICE_ID_MELLANOX_CONNECTX5:
+ case PCI_DEVICE_ID_MELLANOX_CONNECTX5VF:
+ case PCI_DEVICE_ID_MELLANOX_CONNECTX5EX:
+ case PCI_DEVICE_ID_MELLANOX_CONNECTX5EXVF:
+ mps = 1;
+ break;
+ default:
+ mps = 0;
+ }
INFO("PCI information matches, using device \"%s\""
" (SR-IOV: %s, MPS: %s)",
list[i]->name,
@@ -719,6 +735,22 @@ static const struct rte_pci_id mlx5_pci_id_map[] = {
PCI_DEVICE_ID_MELLANOX_CONNECTX4LXVF)
},
{
+ RTE_PCI_DEVICE(PCI_VENDOR_ID_MELLANOX,
+ PCI_DEVICE_ID_MELLANOX_CONNECTX5)
+ },
+ {
+ RTE_PCI_DEVICE(PCI_VENDOR_ID_MELLANOX,
+ PCI_DEVICE_ID_MELLANOX_CONNECTX5VF)
+ },
+ {
+ RTE_PCI_DEVICE(PCI_VENDOR_ID_MELLANOX,
+ PCI_DEVICE_ID_MELLANOX_CONNECTX5EX)
+ },
+ {
+ RTE_PCI_DEVICE(PCI_VENDOR_ID_MELLANOX,
+ PCI_DEVICE_ID_MELLANOX_CONNECTX5EXVF)
+ },
+ {
.vendor_id = 0
}
};
diff --git a/drivers/net/mlx5/mlx5.h b/drivers/net/mlx5/mlx5.h
index c415ce32c..ee62e044e 100644
--- a/drivers/net/mlx5/mlx5.h
+++ b/drivers/net/mlx5/mlx5.h
@@ -83,6 +83,10 @@ enum {
PCI_DEVICE_ID_MELLANOX_CONNECTX4VF = 0x1014,
PCI_DEVICE_ID_MELLANOX_CONNECTX4LX = 0x1015,
PCI_DEVICE_ID_MELLANOX_CONNECTX4LXVF = 0x1016,
+ PCI_DEVICE_ID_MELLANOX_CONNECTX5 = 0x1017,
+ PCI_DEVICE_ID_MELLANOX_CONNECTX5VF = 0x1018,
+ PCI_DEVICE_ID_MELLANOX_CONNECTX5EX = 0x1019,
+ PCI_DEVICE_ID_MELLANOX_CONNECTX5EXVF = 0x101a,
};
struct priv {
diff --git a/drivers/net/mlx5/mlx5_ethdev.c b/drivers/net/mlx5/mlx5_ethdev.c
index 65228d5f9..fbb1b6566 100644
--- a/drivers/net/mlx5/mlx5_ethdev.c
+++ b/drivers/net/mlx5/mlx5_ethdev.c
@@ -1517,14 +1517,11 @@ void
priv_select_tx_function(struct priv *priv)
{
priv->dev->tx_pkt_burst = mlx5_tx_burst;
- /* Display warning for unsupported configurations. */
- if (priv->sriov && priv->mps)
- WARN("multi-packet send WQE cannot be used on a SR-IOV setup");
/* Select appropriate TX function. */
- if ((priv->sriov == 0) && priv->mps && priv->txq_inline) {
+ if (priv->mps && priv->txq_inline) {
priv->dev->tx_pkt_burst = mlx5_tx_burst_mpw_inline;
DEBUG("selected MPW inline TX function");
- } else if ((priv->sriov == 0) && priv->mps) {
+ } else if (priv->mps) {
priv->dev->tx_pkt_burst = mlx5_tx_burst_mpw;
DEBUG("selected MPW TX function");
}
diff --git a/drivers/net/mlx5/mlx5_txq.c b/drivers/net/mlx5/mlx5_txq.c
index 053665d55..4f36402eb 100644
--- a/drivers/net/mlx5/mlx5_txq.c
+++ b/drivers/net/mlx5/mlx5_txq.c
@@ -412,7 +412,7 @@ txq_ctrl_setup(struct rte_eth_dev *dev, struct txq_ctrl *txq_ctrl,
.obj = tmpl.qp,
/* Enable multi-packet send if supported. */
.family_flags =
- ((priv->mps && !priv->sriov) ?
+ (priv->mps ?
IBV_EXP_QP_BURST_CREATE_ENABLE_MULTI_PACKET_SEND_WR :
0),
};
--
2.11.0
^ permalink raw reply related
* Re: [PATCH v7 18/27] app/testpmd: use VFD APIs on i40e
From: Wu, Jingjing @ 2017-01-06 1:16 UTC (permalink / raw)
To: Lu, Wenzhuo, dev@dpdk.org; +Cc: Lu, Wenzhuo, Chen, Jing D, Iremonger, Bernard
In-Reply-To: <1483426488-117332-19-git-send-email-wenzhuo.lu@intel.com>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Wenzhuo Lu
> Sent: Tuesday, January 3, 2017 2:55 PM
> To: dev@dpdk.org
> Cc: Lu, Wenzhuo <wenzhuo.lu@intel.com>; Chen, Jing D
> <jing.d.chen@intel.com>; Iremonger, Bernard <bernard.iremonger@intel.com>
> Subject: [dpdk-dev] [PATCH v7 18/27] app/testpmd: use VFD APIs on i40e
>
> The new VF Daemon (VFD) APIs is implemented on i40e. Change testpmd code
> to use them, including VF MAC anti-spoofing, VF VLAN anti-spoofing, TX
> loopback, VF VLAN strip, VF VLAN insert.
>
> Signed-off-by: Wenzhuo Lu <wenzhuo.lu@intel.com>
> Signed-off-by: Chen Jing D(Mark) <jing.d.chen@intel.com>
> Signed-off-by: Bernard Iremonger <bernard.iremonger@intel.com>
> ---
> app/test-pmd/Makefile | 3 +
> app/test-pmd/cmdline.c | 154 +++++++++++++++++++++++++++++++++++++++-
> ---------
> 2 files changed, 126 insertions(+), 31 deletions(-)
>
> diff --git a/app/test-pmd/Makefile b/app/test-pmd/Makefile index
> 891b85a..66bd38a 100644
> --- a/app/test-pmd/Makefile
> +++ b/app/test-pmd/Makefile
> @@ -58,7 +58,10 @@ SRCS-y += csumonly.c
> SRCS-y += icmpecho.c
> SRCS-$(CONFIG_RTE_LIBRTE_IEEE1588) += ieee1588fwd.c
>
> +ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
> _LDLIBS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += -lrte_pmd_ixgbe
> +_LDLIBS-$(CONFIG_RTE_LIBRTE_I40E_PMD) += -lrte_pmd_i40e endif
>
> CFLAGS_cmdline.o := -D_GNU_SOURCE
>
> diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c index
> ed84d7a..9a44b4f 100644
> --- a/app/test-pmd/cmdline.c
> +++ b/app/test-pmd/cmdline.c
> @@ -90,6 +90,9 @@
> #ifdef RTE_LIBRTE_IXGBE_PMD
> #include <rte_pmd_ixgbe.h>
> #endif
> +#ifdef RTE_LIBRTE_I40E_PMD
> +#include <rte_pmd_i40e.h>
> +#endif
> #include "testpmd.h"
>
> static struct cmdline *testpmd_cl;
> @@ -262,19 +265,19 @@ static void cmd_help_long_parsed(void
> *parsed_result,
> "set portlist (x[,y]*)\n"
> " Set the list of forwarding ports.\n\n"
>
> -#ifdef RTE_LIBRTE_IXGBE_PMD
How about use
#if defined(RTE_LIBRTE_IXGBE_PMD) || defined (RTE_LIBRTE_I40E_PMD)
but not remove it, because this command only works for ixgbe and i40e pmd.
> "set tx loopback (port_id) (on|off)\n"
> " Enable or disable tx loopback.\n\n"
>
> +#ifdef RTE_LIBRTE_IXGBE_PMD
> "set all queues drop (port_id) (on|off)\n"
> " Set drop enable bit for all queues.\n\n"
>
> "set vf split drop (port_id) (vf_id) (on|off)\n"
> " Set split drop enable bit for a VF from the PF.\n\n"
> +#endif
>
> "set vf mac antispoof (port_id) (vf_id) (on|off).\n"
> " Set MAC antispoof for a VF from the PF.\n\n"
> -#endif
>
^ permalink raw reply
* Re: [PATCH v7 19/27] app/testpmd: use unicast promiscuous mode on i40e
From: Wu, Jingjing @ 2017-01-06 1:21 UTC (permalink / raw)
To: Lu, Wenzhuo, dev@dpdk.org; +Cc: Lu, Wenzhuo
In-Reply-To: <1483426488-117332-20-git-send-email-wenzhuo.lu@intel.com>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Wenzhuo Lu
> Sent: Tuesday, January 3, 2017 2:55 PM
> To: dev@dpdk.org
> Cc: Lu, Wenzhuo <wenzhuo.lu@intel.com>
> Subject: [dpdk-dev] [PATCH v7 19/27] app/testpmd: use unicast promiscuous
> mode on i40e
>
> Add testpmd CLI to set VF unicast promiscuous mode on i40e.
>
> Signed-off-by: Wenzhuo Lu <wenzhuo.lu@intel.com>
> ---
> app/test-pmd/cmdline.c | 93 +++++++++++++++++++++++++++++
> doc/guides/testpmd_app_ug/testpmd_funcs.rst | 9 +++
> 2 files changed, 102 insertions(+)
>
> diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c index
> 9a44b4f..affe9d1 100644
> --- a/app/test-pmd/cmdline.c
> +++ b/app/test-pmd/cmdline.c
> @@ -400,6 +400,9 @@ static void cmd_help_long_parsed(void *parsed_result,
> "set allmulti (port_id|all) (on|off)\n"
> " Set the allmulti mode on port_id, or all.\n\n"
>
> + "set vf promisc (port_id) (vf_id) (on|off)\n"
> + " Set unicast promiscuous mode for a VF from the
> PF.\n\n"
> +
> "set flow_ctrl rx (on|off) tx (on|off) (high_water)"
> " (low_water) (pause_time) (send_xon)
> mac_ctrl_frame_fwd"
> " (on|off) autoneg (on|off) (port_id)\n"
> @@ -11559,6 +11562,95 @@ struct cmd_set_vf_mac_addr_result {
> },
> };
>
> +/* VF unicast promiscuous mode configuration */
> +
> +/* Common result structure for VF unicast promiscuous mode */ struct
> +cmd_vf_promisc_result {
> + cmdline_fixed_string_t set;
> + cmdline_fixed_string_t vf;
> + cmdline_fixed_string_t promisc;
> + uint8_t port_id;
> + uint32_t vf_id;
> + cmdline_fixed_string_t on_off;
> +};
> +
> +/* Common CLI fields for VF unicast promiscuous mode enable disable */
> +cmdline_parse_token_string_t cmd_vf_promisc_set =
> + TOKEN_STRING_INITIALIZER
> + (struct cmd_vf_promisc_result,
> + set, "set");
> +cmdline_parse_token_string_t cmd_vf_promisc_vf =
> + TOKEN_STRING_INITIALIZER
> + (struct cmd_vf_promisc_result,
> + vf, "vf");
> +cmdline_parse_token_string_t cmd_vf_promisc_promisc =
> + TOKEN_STRING_INITIALIZER
> + (struct cmd_vf_promisc_result,
> + promisc, "promisc");
> +cmdline_parse_token_num_t cmd_vf_promisc_port_id =
> + TOKEN_NUM_INITIALIZER
> + (struct cmd_vf_promisc_result,
> + port_id, UINT8);
> +cmdline_parse_token_num_t cmd_vf_promisc_vf_id =
> + TOKEN_NUM_INITIALIZER
> + (struct cmd_vf_promisc_result,
> + vf_id, UINT32);
> +cmdline_parse_token_string_t cmd_vf_promisc_on_off =
> + TOKEN_STRING_INITIALIZER
> + (struct cmd_vf_promisc_result,
> + on_off, "on#off");
> +
> +static void
> +cmd_set_vf_promisc_parsed(
> + void *parsed_result,
> + __attribute__((unused)) struct cmdline *cl,
> + __attribute__((unused)) void *data)
> +{
> + struct cmd_vf_promisc_result *res = parsed_result;
> + int ret = -ENOTSUP;
> +
> + __rte_unused int is_on = (strcmp(res->on_off, "on") == 0) ? 1 : 0;
> +
> + if (port_id_is_invalid(res->port_id, ENABLED_WARN))
> + return;
> +
> +#ifdef RTE_LIBRTE_I40E_PMD
> + ret = rte_pmd_i40e_set_vf_unicast_promisc(res->port_id,
> + res->vf_id, is_on);
> +#endif
> +
It's better to wrap the command by +#ifdef RTE_LIBRTE_I40E_PMD #endif
Or at least, need to check if the port is handled i40e pmd.
^ permalink raw reply
* [PATCH] doc: fix a link in contribution guide
From: Yongseok Koh @ 2017-01-06 1:22 UTC (permalink / raw)
To: john.mcnamara; +Cc: dev, Yongseok Koh
A referenced document in the Linux Kernel has been moved to a
sub-directory.
Signed-off-by: Yongseok Koh <yskoh@mellanox.com>
---
doc/guides/contributing/patches.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/doc/guides/contributing/patches.rst b/doc/guides/contributing/patches.rst
index c7006c191..a6bae9172 100644
--- a/doc/guides/contributing/patches.rst
+++ b/doc/guides/contributing/patches.rst
@@ -7,7 +7,7 @@ This document outlines the guidelines for submitting code to DPDK.
The DPDK development process is modelled (loosely) on the Linux Kernel development model so it is worth reading the
Linux kernel guide on submitting patches:
-`How to Get Your Change Into the Linux Kernel <http://www.kernel.org/doc/Documentation/SubmittingPatches>`_.
+`How to Get Your Change Into the Linux Kernel <http://www.kernel.org/doc/Documentation/process/submitting-patches.rst>`_.
The rationale for many of the DPDK guidelines is explained in greater detail in the kernel guidelines.
@@ -192,7 +192,7 @@ Here are some guidelines for the body of a commit message:
git commit --signoff # or -s
The purpose of the signoff is explained in the
- `Developer's Certificate of Origin <http://www.kernel.org/doc/Documentation/SubmittingPatches>`_
+ `Developer's Certificate of Origin <http://www.kernel.org/doc/Documentation/process/submitting-patches.rst>`_
section of the Linux kernel guidelines.
.. Note::
--
2.11.0
^ permalink raw reply related
* Re: [PATCH v7 25/27] net/i40e: set/clear VF stats from PF
From: Wu, Jingjing @ 2017-01-06 1:25 UTC (permalink / raw)
To: Lu, Wenzhuo, dev@dpdk.org; +Cc: Zhang, Qi Z
In-Reply-To: <1483426488-117332-26-git-send-email-wenzhuo.lu@intel.com>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Wenzhuo Lu
> Sent: Tuesday, January 3, 2017 2:55 PM
> To: dev@dpdk.org
> Cc: Zhang, Qi Z <qi.z.zhang@intel.com>
> Subject: [dpdk-dev] [PATCH v7 25/27] net/i40e: set/clear VF stats from PF
>
> From: Qi Zhang <qi.z.zhang@intel.com>
>
> This patch add support to get/clear VF statistics from PF side.
> Two APIs are added:
> rte_pmd_i40e_get_vf_stats.
> rte_pmd_i40e_reset_vf_stats.
>
> Signed-off-by: Qi Zhang <qi.z.zhang@intel.com>
> ---
> drivers/net/i40e/i40e_ethdev.c | 81
> +++++++++++++++++++++++++++++++
> drivers/net/i40e/rte_pmd_i40e.h | 41 ++++++++++++++++
> drivers/net/i40e/rte_pmd_i40e_version.map | 2 +
> 3 files changed, 124 insertions(+)
>
> diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
> index 47e03d6..be45cfa 100644
> --- a/drivers/net/i40e/i40e_ethdev.c
> +++ b/drivers/net/i40e/i40e_ethdev.c
> @@ -10480,3 +10480,84 @@ int rte_pmd_i40e_set_vf_vlan_filter(uint8_t port,
> uint16_t vlan_id,
>
> return ret;
> }
> +
> +int
> +rte_pmd_i40e_get_vf_stats(uint8_t port,
> + uint16_t vf_id,
> + struct rte_eth_stats *stats)
> +{
> + struct rte_eth_dev *dev;
> + struct rte_eth_dev_info dev_info;
> + struct i40e_pf *pf;
> + struct i40e_vsi *vsi;
> + int ret = 0;
> +
> + RTE_ETH_VALID_PORTID_OR_ERR_RET(port, -ENODEV);
> +
> + dev = &rte_eth_devices[port];
> + rte_eth_dev_info_get(port, &dev_info);
> +
> + if (vf_id >= dev_info.max_vfs)
> + return -EINVAL;
> +
> + pf = I40E_DEV_PRIVATE_TO_PF(dev->data->dev_private);
> +
> + if (vf_id > pf->vf_num - 1 || !pf->vfs) {
> + PMD_DRV_LOG(ERR, "Invalid argument.");
> + return -EINVAL;
> + }
> +
> + vsi = pf->vfs[vf_id].vsi;
> + if (!vsi)
> + return -EINVAL;
> +
> + i40e_update_vsi_stats(vsi);
> +
> + stats->ipackets = vsi->eth_stats.rx_unicast +
> + vsi->eth_stats.rx_multicast +
> + vsi->eth_stats.rx_broadcast;
> + stats->opackets = vsi->eth_stats.tx_unicast +
> + vsi->eth_stats.tx_multicast +
> + vsi->eth_stats.tx_broadcast;
> + stats->ibytes = vsi->eth_stats.rx_bytes;
> + stats->obytes = vsi->eth_stats.tx_bytes;
> + stats->ierrors = vsi->eth_stats.rx_discards;
> + stats->oerrors = vsi->eth_stats.tx_errors +
> +vsi->eth_stats.tx_discards;
> +
> + return ret;
It looks ret is not changed in this func at all.
> +}
> +
> +int
> +rte_pmd_i40e_reset_vf_stats(uint8_t port,
> + uint16_t vf_id)
> +{
> + struct rte_eth_dev *dev;
> + struct rte_eth_dev_info dev_info;
> + struct i40e_pf *pf;
> + struct i40e_vsi *vsi;
> + int ret = 0;
> +
> + RTE_ETH_VALID_PORTID_OR_ERR_RET(port, -ENODEV);
> +
> + dev = &rte_eth_devices[port];
> + rte_eth_dev_info_get(port, &dev_info);
> +
> + if (vf_id >= dev_info.max_vfs)
> + return -EINVAL;
> +
> + pf = I40E_DEV_PRIVATE_TO_PF(dev->data->dev_private);
> +
> + if (vf_id > pf->vf_num - 1 || !pf->vfs) {
> + PMD_DRV_LOG(ERR, "Invalid argument.");
> + return -EINVAL;
> + }
> +
> + vsi = pf->vfs[vf_id].vsi;
> + if (!vsi)
> + return -EINVAL;
> +
> + vsi->offset_loaded = false;
> + i40e_update_vsi_stats(vsi);
> +
> + return ret;
Same comment as above.
^ permalink raw reply
* Re: [PATCH v7 26/27] net/i40e: fix segmentation fault in close
From: Wu, Jingjing @ 2017-01-06 1:29 UTC (permalink / raw)
To: Lu, Wenzhuo, dev@dpdk.org; +Cc: Iremonger, Bernard, stable@dpdk.org
In-Reply-To: <1483426488-117332-27-git-send-email-wenzhuo.lu@intel.com>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Wenzhuo Lu
> Sent: Tuesday, January 3, 2017 2:55 PM
> To: dev@dpdk.org
> Cc: Iremonger, Bernard <bernard.iremonger@intel.com>; stable@dpdk.org
> Subject: [dpdk-dev] [PATCH v7 26/27] net/i40e: fix segmentation fault in close
>
> From: Bernard Iremonger <bernard.iremonger@intel.com>
>
> The vsi's have already been released, so the second call to i40e_vsi_release
> results in a segmentation fault.
> The second call to i40e_vsi_release has been removed.
Where is the first call to release vmdq vsi?
Thanks
Jingjing
>
> Fixes: 3cb446b4aeb2 ("i40e: free vmdq vsi when closing")
>
> CC: stable@dpdk.org
>
> Signed-off-by: Bernard Iremonger <bernard.iremonger@intel.com>
> ---
> drivers/net/i40e/i40e_ethdev.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
> index be45cfa..0b7c366 100644
> --- a/drivers/net/i40e/i40e_ethdev.c
> +++ b/drivers/net/i40e/i40e_ethdev.c
> @@ -1882,7 +1882,6 @@ static inline void i40e_GLQF_reg_init(struct i40e_hw
> *hw)
> i40e_vsi_release(pf->main_vsi);
>
> for (i = 0; i < pf->nb_cfg_vmdq_vsi; i++) {
> - i40e_vsi_release(pf->vmdq[i].vsi);
> pf->vmdq[i].vsi = NULL;
> }
>
> @@ -4137,6 +4136,9 @@ enum i40e_status_code
> if (!vsi)
> return I40E_SUCCESS;
>
> + if (!vsi->adapter)
> + return I40E_ERR_BAD_PTR;
> +
> user_param = vsi->user_param;
>
> pf = I40E_VSI_TO_PF(vsi);
> --
> 1.9.3
^ permalink raw reply
* Re: [PATCH 2/6] i40e: don't refer to eth_dev->pci_dev
From: Wu, Jingjing @ 2017-01-06 1:50 UTC (permalink / raw)
To: Stephen Hemminger, dev@dpdk.org; +Cc: Stephen Hemminger
In-Reply-To: <20170102230850.32610-3-sthemmin@microsoft.com>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Stephen Hemminger
> Sent: Tuesday, January 3, 2017 7:09 AM
> To: dev@dpdk.org
> Cc: Stephen Hemminger <sthemmin@microsoft.com>
> Subject: [dpdk-dev] [PATCH 2/6] i40e: don't refer to eth_dev->pci_dev
>
> Later patches remove pci_dev from the ethernet device structure.
> Fix the i40e code to just use it's own name when forming zone name.
>
> Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
Acked-by: Jingjing Wu <jingjing.wu@intel.com>
^ 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