[dpdk-dev] [PATCH v6 0/4] support reset of VF link
> > Unfortunately I found one issue: if PF is down, and then the VF on the guest > is > down as well (ip link down) and then goes back up before the PF, then calling > rte_eth_dev_reset will return 0 (success), even though the PF is still down > and it > should fail. This is with ixgbe. Any idea what could be the problem? I've found this interesting thing. I believe it?s the HW difference between igb and ixgbe. When the link is down, ixgbe VF can be reset successfully but igb VF cannot. The expression is the registers of the ixgbe VF can be accessed when the PF link is down but igb VF cannot. It means, on ixgbe, when PF link is down, we reset the VF link. Then PF link is up, we receive the message again and reset the VF link again. But on igb, when PF link is down, we cannot reset VF link successfully, so when the PF link is up, we cannot receive the message. No trigger for us to reset the VF link again. That's why on igb we have to try again and again until it succeed, means until PF link is up. So the return 0 by rte_eth_dev_reset means the resetting succeeded, not mean the rx/tx is ready. Rx/tx has to depend on the PF link is up. > > -- > Kind regards, > Luca Boccassi
[dpdk-dev] [PATCH] vhost: reset queue state in destroy_device
On Mon, Jul 04, 2016 at 10:24:41AM +0800, Yuanhan Liu wrote:
> On Fri, Jul 01, 2016 at 09:31:12AM -0700, Rich Lane wrote:
> > Fixes a bug where rte_eth_vhost_get_queue_event would not return enabled
> > queues
> > after a guest application restart.
> >
> > Fixes: ee584e9710b9 ("vhost: add driver on top of the library")
> > Signed-off-by: Rich Lane
>
> Acked-by: Yuanhan Liu
>
> Just some minor comments about the title (nothing big deal; it's just
> some DPDK preferences):
>
> - a bug fix patch need be titled as "fix ..."
>
> - it's better to hide specific function in the title. If you run
> "scripts/check-git-log.sh", you will find a warning.
>
> - the prefix should be "net/vhost".
>
> So, I'd like to reword the title a bit, to something like:
>
> "net/vhost: fix queue state not reset on destroy"
>
> If have no objection, I could fix it while apply.
Applied to dpdk-next-virtio, with above minor fixes included.
Thanks.
--yliu
[dpdk-dev] [PATCH] examples/vhost: fix failure without hints
On Mon, Jul 04, 2016 at 11:00:13AM +0800, Yuanhan Liu wrote:
> On Fri, Jul 01, 2016 at 08:50:31AM +, Jianfeng Tan wrote:
> > When the specified cores and memory lie on different numa socket with
> > physical NIC, vhost fails to set up rx queue, and exits without any
> > hints. This could leads to confusion of users.
> >
> > This patch fixes it by adding some error messages when calling ether
> > APIs returns errors.
> >
> > Fixes: 4796ad63ba1f ("examples/vhost: import userspace vhost application")
>
> I will not call it a "fix", instead, it's an "enhancement" to me.
>
> > Reported-by: Yulong Pei
>
> And since it's not a bug, it might be "Suggested-by: ...".
Applied to dpdk-next-virtio, with some commit log rewords.
Thanks.
--yliu
[dpdk-dev] [PATCH] net/virtio: fix gcc6 i686 compiler error
On Thu, Jul 07, 2016 at 02:49:08PM +0100, Ferruh Yigit wrote:
> This is for target i686-native-linuxapp-gcc and gcc6,
>
> Compilation error is:
> == Build drivers/net/virtio
> CC virtio_rxtx_simple.o
> In file included from
> .../build/include/rte_mempool.h:77:0,
> from
> .../drivers/net/virtio/virtio_rxtx_simple.c:46:
> .../drivers/net/virtio/virtio_rxtx_simple.c: In
> function ?virtio_xmit_pkts_simple?:
> .../build/include/rte_memcpy.h:551:2: error: array
> subscript is above array bounds [-Werror=array-bounds]
> rte_mov16((uint8_t *)dst + 1 * 16, (const uint8_t *)src + 1 * 16);
> ^
>
...
>
> The compiler traces the array all through the call stack and knows the
> size of array is 128 and generates a warning on above [1] which tries to
> access beyond byte 128.
> But unfortunately it ignores the "(size > 256)" check.
>
> Giving a hint to compiler that variable "size" is related to the size of
> the source buffer fixes compiler warning.
>
> Fixes: 863bfb474493 ("mempool: optimize copy in cache")
>
> Signed-off-by: Ferruh Yigit
Applied to dpdk-next-virtio.
Thanks.
--yliu
[dpdk-dev] [RFC] Generic flow director/filtering/classification API
Hi Adrien,
Thanks so much for the explanation.
> -Original Message-
> From: Adrien Mazarguil [mailto:adrien.mazarguil at 6wind.com]
> Sent: Friday, July 08, 2016 9:26 PM
> To: Liang, Cunming
> Cc: dev at dpdk.org; Thomas Monjalon ; Zhang,
> Helin ; Wu, Jingjing ;
> Rasesh
> Mody ; Ajit Khaparde
> ; Rahul Lakkireddy
> ; Lu, Wenzhuo ; Jan
> Medala ; John Daley ; Chen, Jing D
> ; Ananyev, Konstantin
> ; Matej Vido ;
> Alejandro Lucero ; Sony Chacko
> ; Jerin Jacob ;
> De
> Lara Guarch, Pablo ; Olga Shern
>
> Subject: Re: [dpdk-dev] [RFC] Generic flow director/filtering/classification
> API
>
> Hi Cunming,
>
> I agree with Bruce, I'll start snipping non relevant parts considering the
> size of this message. Please see below.
>
> On Fri, Jul 08, 2016 at 07:11:28PM +0800, Liang, Cunming wrote:
> [...]
> > >Meta item types
> > >~~~
> > >
> > >These do not match packet data but affect how the pattern is processed,
> > >most
> > >of them do not need a specification structure. This particularity allows
> > >them to be specified anywhere without affecting other item types.
> > [LC] For the meta item(END, VOID, INVERT) and some data matching type like
> > ANY and RAW,
> > it's all PMD responsible to understand the key character and to parse the
> > header graph?
>
> We haven't started on the PMD side of things yet (the public API described
> here does not discuss it), but I think PMDs will see the pattern as-is,
> untranslated (to answer your question, yes, it will be the case for END,
> VOID, INVERT, ANY and RAW like all others).
>
> However I intend to add private helper functions as needed in librte_ether
> (or anywhere else in EAL) that PMDs can call to ease parsing and validation
> of flow rules, otherwise most of them will end up implementing redundant
> functions.
[LC] Agree, that's very helpful.
>
> [...]
> > >When several actions are combined in a flow rule, they should all have
> > >different types (e.g. dropping a packet twice is not possible). However
> > >considering the VOID type is an exception to this rule, the defined
> > >behavior
> > >is for PMDs to only take into account the last action of a given type found
> > >in the list. PMDs still perform error checking on the entire list.
> > >
> > >*Note that PASSTHRU is the only action able to override a terminating
> > >rule.*
> > [LC] I'm wondering how to address the meta data carried by mbuf, there's no
> > mentioned here.
> > For packets hit one specific flow, usually there's something for CPU to
> > identify the flow.
> > FDIR and RSS as an example, has id or key in mbuf. In addition, some meta
> > may pointed by userdata in mbuf.
> > Any view on it ?
>
> Yes, this is defined as the ID action. It is described in 4.1.6.4 (ID) and
> there is an example how a FDIR rule would be converted to use it in 5.7
> (FDIR to most item types ? QUEUE, DROP, PASSTHRU).
[LC] So in RSS cases, the actions would be {RSS, ID}, in which ID represent for
RSS key, right?
>
> It is basically described as a flow rule with two actions: queue redirection
> and packet tagging.
>
> Does it answer your question?
[LC] I think so, Thanks.
>
> --
> Adrien Mazarguil
> 6WIND
[dpdk-dev] [RFC] remove vhost-cuse
It's something echoed around in my mind for a long while, and here I'm gonna make it public: a proposal to remove vhost-cuse. Vhost-cuse was invented before vhost-user exist. The both are actually doing the same thing: a vhost-net implementation in user space. But they are not exactly the same thing. Firstly, vhost-cuse is harder for use; no one seems to care it, either. Furthermore, since v2.1, a large majority of development effort has gone to vhost-user. For example, we extended the vhost-user spec to add the multiple queue support. We also added the vhost-user live migration at v16.04 and the latest one, vhost-user reconnect that allows vhost app restart without restarting the guest. Both of them are very important features for product usage and none of them works for vhost-cuse. You now see that the difference between vhost-user and vhost-cuse is big (and will be bigger and bigger as time moves forward), that you should never use vhost-cuse, that we should drop it completely. The remove would also result to a much cleaner code base, allowing us to do all kinds of extending easier. A talk with Huawei offline showed that he backs this proposal. I was also told by Ciara that she actually had the same idea: she has already cooked a patch to remove vhost-cuse support from OVS: http://openvswitch.org/pipermail/dev/2016-July/074696.html So I'm proposing to mark vhost-cuse as deprecated in this release and remove it completely at the next release (v16.11). Comments/thoughts, or objections? --yliu
[dpdk-dev] [PATCH] i40e: move PCI device ids to driver
move PCI device ids from rte_pci_dev_ids.h to driver.
Signed-off-by: Jingjing Wu
---
drivers/net/i40e/i40e_ethdev.c | 21 ++--
drivers/net/i40e/i40e_ethdev_vf.c | 9 ++--
lib/librte_eal/common/include/rte_pci_dev_ids.h | 71 -
3 files changed, 24 insertions(+), 77 deletions(-)
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 31c2e11..e75d911 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -454,9 +454,24 @@ static void i40e_set_default_mac_addr(struct rte_eth_dev
*dev,
static int i40e_dev_mtu_set(struct rte_eth_dev *dev, uint16_t mtu);
static const struct rte_pci_id pci_id_i40e_map[] = {
-#define RTE_PCI_DEV_ID_DECL_I40E(vend, dev) {RTE_PCI_DEVICE(vend, dev)},
-#include "rte_pci_dev_ids.h"
-{ .vendor_id = 0, /* sentinel */ },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_SFP_XL710) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_QEMU) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_KX_B) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_KX_C) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_QSFP_A) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_QSFP_B) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_QSFP_C) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_10G_BASE_T) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_20G_KR2) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_20G_KR2_A) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_10G_BASE_T4) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_X722_A0) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_KX_X722) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_QSFP_X722) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_SFP_X722) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_1G_BASE_T_X722) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_10G_BASE_T_X722) },
+ { .vendor_id = 0, /* sentinel */ },
};
static const struct eth_dev_ops i40e_eth_dev_ops = {
diff --git a/drivers/net/i40e/i40e_ethdev_vf.c
b/drivers/net/i40e/i40e_ethdev_vf.c
index 31547db..a616ae0 100644
--- a/drivers/net/i40e/i40e_ethdev_vf.c
+++ b/drivers/net/i40e/i40e_ethdev_vf.c
@@ -1110,9 +1110,12 @@ i40evf_get_link_status(struct rte_eth_dev *dev, struct
rte_eth_link *link)
}
static const struct rte_pci_id pci_id_i40evf_map[] = {
-#define RTE_PCI_DEV_ID_DECL_I40EVF(vend, dev) {RTE_PCI_DEVICE(vend, dev)},
-#include "rte_pci_dev_ids.h"
-{ .vendor_id = 0, /* sentinel */ },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_VF) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_VF_HV) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_X722_A0_VF) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_X722_VF) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_X722_VF_HV) },
+ { .vendor_id = 0, /* sentinel */ },
};
static inline int
diff --git a/lib/librte_eal/common/include/rte_pci_dev_ids.h
b/lib/librte_eal/common/include/rte_pci_dev_ids.h
index af39fbb..9a06313 100644
--- a/lib/librte_eal/common/include/rte_pci_dev_ids.h
+++ b/lib/librte_eal/common/include/rte_pci_dev_ids.h
@@ -74,8 +74,6 @@
* RTE_PCI_DEV_ID_DECL_IGBVF
* RTE_PCI_DEV_ID_DECL_IXGBE
* RTE_PCI_DEV_ID_DECL_IXGBEVF
- * RTE_PCI_DEV_ID_DECL_I40E
- * RTE_PCI_DEV_ID_DECL_I40EVF
* RTE_PCI_DEV_ID_DECL_VIRTIO
* at the time when this file is included.
*
@@ -117,14 +115,6 @@
#define RTE_PCI_DEV_ID_DECL_IXGBEVF(vend, dev)
#endif
-#ifndef RTE_PCI_DEV_ID_DECL_I40E
-#define RTE_PCI_DEV_ID_DECL_I40E(vend, dev)
-#endif
-
-#ifndef RTE_PCI_DEV_ID_DECL_I40EVF
-#define RTE_PCI_DEV_ID_DECL_I40EVF(vend, dev)
-#endif
-
#ifndef RTE_PCI_DEV_ID_DECL_VIRTIO
#define RTE_PCI_DEV_ID_DECL_VIRTIO(vend, dev)
#endif
@@ -528,52 +518,6 @@ RTE_PCI_DEV_ID_DECL_IXGBE(PCI_VENDOR_ID_INTEL,
IXGBE_DEV_ID_X550EM_X_KR)
RTE_PCI_DEV_ID_DECL_IXGBE(PCI_VENDOR_ID_INTEL, IXGBE_DEV_ID_82599_BYPASS)
#endif
-/*** Physical I40E devices from i40e_type.h */
-
-#define I40E_DEV_ID_SFP_XL710 0x1572
-#define I40E_DEV_ID_QEMU0x1574
-#define I40E_DEV_ID_KX_B0x1580
-#define I40E_DEV_ID_KX_C0x1581
-#define I40E_DEV_ID_QSFP_A 0x1583
-#define I40E_DEV_ID_QSFP_B 0x1584
-#define I40E_DEV_ID_QSFP_C 0x1585
-#define I40E_DEV_ID_10G_BASE_T 0x1586
-#define I40E_DEV_ID_20G_KR2 0x1587
-#define I40E_DEV_ID_20G_KR2_A 0x1588
-#define I40E_DEV_ID_10G_BASE_T4 0x1589
-#define I40E_DEV_ID_25G_B 0x158A
-#define I40E_DEV_ID_25G_SFP28 0x158B
-#define I40E_DEV_ID_X722_A0 0x374C
-#define I40E_DEV_ID_KX_X722 0x37CE
-#define I40E_DEV_ID_QSFP_X722 0x37CF
-#defi
[dpdk-dev] [dpdk-dev, 1/3] rte_interrupts: add rte_eal_intr_exit to shut down IRQ thread
Hi Thomas, Base on the previous conversation, at least it requires v2 to reword some comments. > > >> 2. I propose to add addition comments on rte_epoll_wait() API > > >> description. For any signal, it causes an error return, user needs > > >> to handle. > > > Agreed. In addition, one conversion is not close. > > >> the default termination handler > > > I am not so experienced with this "default termination handler". Can > someone > > > clarify what it is so I could comment better about it? > > For example, you're handling SIGINT. After finishing your necessary app > > cleanup, then 'signal(SIGINT, SIG_DFL); raise(SIGINT);'. > > The default signal handler can terminate the interrupt thread. > > >> 1. Can you explain and add patch comments why default signal handler > > >> is not good enough to terminate app. > > > Yes if someone call tell me more about what it is so I can check it. Thanks, Cunming > -Original Message- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Saturday, July 09, 2016 1:36 AM > To: Liang, Cunming > Cc: Matthew Hall ; dev at dpdk.org > Subject: Re: [dpdk-dev,1/3] rte_interrupts: add rte_eal_intr_exit to shut down > IRQ thread > > Cunming, what is the status of this patchset, please? > > 2016-03-23 11:24, Liang, Cunming: > > Hi Mattew, > > > > Thank you for your time. > > > > On 3/22/2016 3:39 PM, Matthew Hall wrote: > > > On Mon, Mar 21, 2016 at 03:58:44PM +0800, Liang, Cunming wrote: > > >> the default termination handler > > > I am not so experienced with this "default termination handler". Can > someone > > > clarify what it is so I could comment better about it? > > For example, you're handling SIGINT. After finishing your necessary app > > cleanup, then 'signal(SIGINT, SIG_DFL); raise(SIGINT);'. > > The default signal handler can terminate the interrupt thread. > > > > > > > >> If EINTR is caused by some non-term purpose signals, are you going > > >> to exit the interrupt thread any way? > > > We should discuss what makes sense here. I'm just trying to get some > > > things > > > working and finding EINTR was getting eaten and causing infinite looping. > > SIGINT/SIGTERM causes EINTR return, while SIGUSR1 also can cause the > > EINTR return. For the dedicated EAL interrupt thread, it won't be > > expected to exit for all kinds of the cause. > > On this view, I'm in favor of your patch which cancel the interrupt > > thread, but don't directly return by the EINTR. > > > > > > > >> Without setting 'PTHREAD_CREATE_DETACHED' won't cause the infinite > > >> loop. However by using pthread_cancel to terminate the thread, > > >> indeed it's necessary to set 'PTHREAD_CREATE_DETACHED'. > > > My general understanding is that PTHREAD_CREATE_DETACHED should be > used for > > > any thread, which should not keep a process open by itself if it is > > > executing, > > > i.e. a "daemon thread". I believe the interrupt thread qualifies as such a > > > thread if I have understood everything right (which is hard to promise > > > when > > > you only work in DPDK in spare time). > > > > > >> It looks like 'pthread_cancel' is the right way and I saw it > > >> continue keeps current EINTR handling in EAL interrupt thread. > > > It is one option. Depending what makes the most sense. > > > > > >> 1. Can you explain and add patch comments why default signal handler > > >> is not good enough to terminate app. > > > Yes if someone call tell me more about what it is so I can check it. > > > > > >> 2. I propose to add addition comments on rte_epoll_wait() API > > >> description. For any signal, it causes an error return, user needs > > >> to handle. > > > Agreed. > > > > > >> 3. Will you do a favorite to add 'PTHREAD_CREATE_DETACHED' to all > > >> EAL pthread too. > > > As a spare time developer I am a bit conservative about too large of a > > > scope > > > and messing with code for other threads or features I didn't personally > > > use or > > > test. This is because I don't have the same QA resources as Intel / 6WIND > > > / > > > etc.. Some help from a full time developer would be great here. > > All right, reasonable to me. > > > > > > > >> Cunming > > > Matthew. > > >
[dpdk-dev] Ignoring number of bytes read in eal
Hello, On Tue, Jun 28, 2016 at 10:40 AM, Kobylinski, MichalX wrote: > CID 13212 - Ignoring number of bytes read: > The number of bytes copied into the buffer can be smaller than the requested > number and the buffer can potentially be accessed out of range. > In rte_mem_virt2phy: Value returned from a function and indicating the number > of bytes read is ignored. > > File: /lib/librte_eal/linuxapp/eal/eal_memory.c > Line: 187 > > Can I mark this error as "False Positive"? > > Because return from read function is checked in "if" condition. If return > from read is less than 0 function rte_mem_virt2phy is aborted and return: log > message, RTE_BAD_PHYS_ADDR. ? Coverity is complaining because (in theory) read can return less than sizeof(uint64_t). This most likely can't happen, but still coverity is right from my pov. I'd rather fix this than mark this as false positive, Sergio ? -- David Marchand
[dpdk-dev] [PATCH] doc: announce driver name changes
Hi, I'm all in for consistent naming and this "only" is the deprecation notice ahead of time which is great. Looking ahead I wanted to ask for opinions if more than just me would consider it useful to keep aliases on the old names when the rename happens. That way any sort of old config would continue to work. Of course I could do that in the scope of the scripts that consume the names and apply the driver loads. But then that is true for everybody out there who has some kind of config/tooling around the old names - so I thought it is worth to ask for opinions. Kind Regards, Christian Christian Ehrhardt Software Engineer, Ubuntu Server Canonical Ltd On Sat, Jul 9, 2016 at 6:56 PM, Pablo de Lara < pablo.de.lara.guarch at intel.com> wrote: > Driver names for all the supported devices in DPDK do not have > a naming convention. Some are using a prefix, some are not > and some have long names. Driver names are used when creating > virtual devices, so it is useful to have consistency in the names. > > Signed-off-by: Pablo de Lara > --- > doc/guides/rel_notes/deprecation.rst | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/doc/guides/rel_notes/deprecation.rst > b/doc/guides/rel_notes/deprecation.rst > index f502f86..37d65c8 100644 > --- a/doc/guides/rel_notes/deprecation.rst > +++ b/doc/guides/rel_notes/deprecation.rst > @@ -41,3 +41,8 @@ Deprecation Notices > * The mempool functions for single/multi producer/consumer are deprecated > and >will be removed in 16.11. >It is replaced by rte_mempool_generic_get/put functions. > + > +* Driver names are quite inconsistent among each others and they will be > + renamed to something more consistent (net_ prefix for net drivers and > + crypto_ for crypto drivers) in 16.11. Some of these driver names are > used > + publicly, to create virtual devices, so a deprecation notice is > necessary. > -- > 2.7.4 > >
[dpdk-dev] [PATCH v3 01/13] e1000: move pci device ids to driver
On Fri, Jul 08, 2016 at 03:31:27PM +0200, Thomas Monjalon wrote: > 2016-04-20 14:43, David Marchand: > > test application and kni still want to know e1000 pci devices. > > So let's create headers in the driver that will be used by them. > > There is also an usage of ixgbe ID for the broken bypass API. > > Sharing those PCI ids outside of the drivers was really a wrong idea. > So this a plan to get rid of them: > > 1/ remove need in PCI autotest (done: http://dpdk.org/commit/1dbba165) > 2/ move PCI ids in bnx2x, bnxt, e1000, enic, fm10k, i40e, virtio, vmxnet3 > 3/ remove KNI ethtool (only igb/ixgbe support) > 4/ remove bypass API or move it to ixgbe specific API > 5/ move remaining PCI ids in igb and ixgbe drivers > > Please driver maintainers, move your PCI ids in your drivers as soon as > possible. Thanks Hi Thomas, I'm not quite sure I understood it well: are you asking us to resend what David has already send, say me for resending the virtio part? If so, what's the point of that? What's worse, it's likely to fail apply (due to conflicts), as every one of us make a patch based on the same base while touching some same files. --yliu
[dpdk-dev] [PATCH v2 1/2] doc: add bifurcated driver guide on ixgbe nic
> -Original Message- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Friday, July 8, 2016 5:14 PM > To: Wu, Jingjing > Cc: dev at dpdk.org; Mcnamara, John; Liu, Yong; Zhang, Helin; Iremonger, > Bernard > Subject: Re: [dpdk-dev] [PATCH v2 1/2] doc: add bifurcated driver guide on > ixgbe nic > > 2016-07-08 08:42, Wu, Jingjing: > > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > > > Thank you for providing more doc. > > > I am just not convinced it is the right place and it must be > > > discussed. > > > Some questions below to help deciding where it must be. > > > > > > 2016-06-23 11:02, Jingjing Wu: > > > > Bifurcated driver is a mechanism which depends the advanced > > > > Ethernet device to split traffic between queues. It provides the > > > > capability to let the kernel driver and DPDK driver co-exist and > > > > take their advantage. > > > > > > The name "bifurcated driver" was used for a real driver proposal in > > > Linux. I don't think it applies here. > > Where does the "bifurcated" name come from? > Could we rename it to "flow bifurcation" or "partial kernel bypass"? > It is our internal name. It is also called as queue split between drivers. And I like the "flow bifurcation" one, let me rename it. Thanks for the suggestion. > > > > It is achieved by using SRIOV and NIC's advanced filtering. This > > > > patch describes it and adds the user guide on ixgbe NICs. > > > > > > It is not a DPDK feature, just a use case. > > > What do we learn about DPDK? > > > > Yes, it is an feature in Linux driver. And the typical use case how DPDK co- > work with Linux networking. > > I think it will be a good reference. When I preparde this patch, I'm > > also doubt where to put, and the behavior may be NIC specific, so I added > it here. > > > > Any other suggestion? > > Bernard is creating an howto section. Yes, just saw it. Will re-organize it to howto.
[dpdk-dev] [PATCH v3 01/13] e1000: move pci device ids to driver
2016-07-11 13:33, Yuanhan Liu: > On Fri, Jul 08, 2016 at 03:31:27PM +0200, Thomas Monjalon wrote: > > 2016-04-20 14:43, David Marchand: > > > test application and kni still want to know e1000 pci devices. > > > So let's create headers in the driver that will be used by them. > > > > There is also an usage of ixgbe ID for the broken bypass API. > > > > Sharing those PCI ids outside of the drivers was really a wrong idea. > > So this a plan to get rid of them: > > > > 1/ remove need in PCI autotest (done: http://dpdk.org/commit/1dbba165) > > 2/ move PCI ids in bnx2x, bnxt, e1000, enic, fm10k, i40e, virtio, vmxnet3 > > 3/ remove KNI ethtool (only igb/ixgbe support) > > 4/ remove bypass API or move it to ixgbe specific API > > 5/ move remaining PCI ids in igb and ixgbe drivers > > > > Please driver maintainers, move your PCI ids in your drivers as soon as > > possible. Thanks > > Hi Thomas, > > I'm not quite sure I understood it well: are you asking us to resend > what David has already send, say me for resending the virtio part? > > If so, what's the point of that? What's worse, it's likely to fail > apply (due to conflicts), as every one of us make a patch based on > the same base while touching some same files. Good point. There were some changes since the patches from David (and a new bnxt). That's why I was thinking to ask maintainers to take care of this change. But maybe it's better to do the change in one patchset. David, ok to refresh these patches?
[dpdk-dev] [PATCH v3 01/13] e1000: move pci device ids to driver
On Mon, Jul 11, 2016 at 07:56:16AM +0200, Thomas Monjalon wrote: > 2016-07-11 13:33, Yuanhan Liu: > > On Fri, Jul 08, 2016 at 03:31:27PM +0200, Thomas Monjalon wrote: > > > 2016-04-20 14:43, David Marchand: > > > > test application and kni still want to know e1000 pci devices. > > > > So let's create headers in the driver that will be used by them. > > > > > > There is also an usage of ixgbe ID for the broken bypass API. > > > > > > Sharing those PCI ids outside of the drivers was really a wrong idea. > > > So this a plan to get rid of them: > > > > > > 1/ remove need in PCI autotest (done: http://dpdk.org/commit/1dbba165) > > > 2/ move PCI ids in bnx2x, bnxt, e1000, enic, fm10k, i40e, virtio, vmxnet3 > > > 3/ remove KNI ethtool (only igb/ixgbe support) > > > 4/ remove bypass API or move it to ixgbe specific API > > > 5/ move remaining PCI ids in igb and ixgbe drivers > > > > > > Please driver maintainers, move your PCI ids in your drivers as soon as > > > possible. Thanks > > > > Hi Thomas, > > > > I'm not quite sure I understood it well: are you asking us to resend > > what David has already send, say me for resending the virtio part? > > > > If so, what's the point of that? What's worse, it's likely to fail > > apply (due to conflicts), as every one of us make a patch based on > > the same base while touching some same files. > > Good point. > There were some changes since the patches from David (and a new bnxt). > That's why I was thinking to ask maintainers to take care of this change. > But maybe it's better to do the change in one patchset. Yes, I'd think so. --yliu > David, ok to refresh these patches?
[dpdk-dev] [PATCH] i40e: move PCI device ids to driver
Hi Jingjing
I'd suggest to add a new header file in each PMD to define what we defined in
rte_pci_dev_ids.h.
There was a patch set submitted several months ago, like that.
Regards,
Helin
> -Original Message-
> From: Wu, Jingjing
> Sent: Monday, July 11, 2016 12:01 PM
> To: thomas.monjalon at 6wind.com
> Cc: Zhang, Helin ; dev at dpdk.org; Wu, Jingjing
>
> Subject: [PATCH] i40e: move PCI device ids to driver
>
> move PCI device ids from rte_pci_dev_ids.h to driver.
>
> Signed-off-by: Jingjing Wu
> ---
> drivers/net/i40e/i40e_ethdev.c | 21 ++--
> drivers/net/i40e/i40e_ethdev_vf.c | 9 ++--
> lib/librte_eal/common/include/rte_pci_dev_ids.h | 71
> -
> 3 files changed, 24 insertions(+), 77 deletions(-)
>
> diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
> index 31c2e11..e75d911 100644
> --- a/drivers/net/i40e/i40e_ethdev.c
> +++ b/drivers/net/i40e/i40e_ethdev.c
> @@ -454,9 +454,24 @@ static void i40e_set_default_mac_addr(struct
> rte_eth_dev *dev, static int i40e_dev_mtu_set(struct rte_eth_dev *dev,
> uint16_t mtu);
>
> static const struct rte_pci_id pci_id_i40e_map[] = { -#define
> RTE_PCI_DEV_ID_DECL_I40E(vend, dev) {RTE_PCI_DEVICE(vend, dev)},
> -#include "rte_pci_dev_ids.h"
> -{ .vendor_id = 0, /* sentinel */ },
> + { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_SFP_XL710) },
> + { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_QEMU) },
> + { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_KX_B) },
> + { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_KX_C) },
> + { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_QSFP_A) },
> + { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_QSFP_B) },
> + { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_QSFP_C) },
> + { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_10G_BASE_T) },
> + { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_20G_KR2) },
> + { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_20G_KR2_A) },
> + { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_10G_BASE_T4) },
> + { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_X722_A0) },
> + { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_KX_X722) },
> + { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_QSFP_X722) },
> + { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_SFP_X722) },
> + { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID,
> I40E_DEV_ID_1G_BASE_T_X722) },
> + { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID,
> I40E_DEV_ID_10G_BASE_T_X722) },
> + { .vendor_id = 0, /* sentinel */ },
> };
>
> static const struct eth_dev_ops i40e_eth_dev_ops = { diff --git
> a/drivers/net/i40e/i40e_ethdev_vf.c b/drivers/net/i40e/i40e_ethdev_vf.c
> index 31547db..a616ae0 100644
> --- a/drivers/net/i40e/i40e_ethdev_vf.c
> +++ b/drivers/net/i40e/i40e_ethdev_vf.c
> @@ -1110,9 +1110,12 @@ i40evf_get_link_status(struct rte_eth_dev *dev,
> struct rte_eth_link *link) }
>
> static const struct rte_pci_id pci_id_i40evf_map[] = { -#define
> RTE_PCI_DEV_ID_DECL_I40EVF(vend, dev) {RTE_PCI_DEVICE(vend, dev)},
> -#include "rte_pci_dev_ids.h"
> -{ .vendor_id = 0, /* sentinel */ },
> + { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_VF) },
> + { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_VF_HV) },
> + { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_X722_A0_VF) },
> + { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_X722_VF) },
> + { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_X722_VF_HV) },
> + { .vendor_id = 0, /* sentinel */ },
> };
>
> static inline int
> diff --git a/lib/librte_eal/common/include/rte_pci_dev_ids.h
> b/lib/librte_eal/common/include/rte_pci_dev_ids.h
> index af39fbb..9a06313 100644
> --- a/lib/librte_eal/common/include/rte_pci_dev_ids.h
> +++ b/lib/librte_eal/common/include/rte_pci_dev_ids.h
> @@ -74,8 +74,6 @@
> * RTE_PCI_DEV_ID_DECL_IGBVF
> * RTE_PCI_DEV_ID_DECL_IXGBE
> * RTE_PCI_DEV_ID_DECL_IXGBEVF
> - * RTE_PCI_DEV_ID_DECL_I40E
> - * RTE_PCI_DEV_ID_DECL_I40EVF
> * RTE_PCI_DEV_ID_DECL_VIRTIO
> * at the time when this file is included.
> *
> @@ -117,14 +115,6 @@
> #define RTE_PCI_DEV_ID_DECL_IXGBEVF(vend, dev) #endif
>
> -#ifndef RTE_PCI_DEV_ID_DECL_I40E
> -#define RTE_PCI_DEV_ID_DECL_I40E(vend, dev) -#endif
> -
> -#ifndef RTE_PCI_DEV_ID_DECL_I40EVF
> -#define RTE_PCI_DEV_ID_DECL_I40EVF(vend, dev) -#endif
> -
> #ifndef RTE_PCI_DEV_ID_DECL_VIRTIO
> #define RTE_PCI_DEV_ID_DECL_VIRTIO(vend, dev) #endif @@ -528,52 +518,6
> @@ RTE_PCI_DEV_ID_DECL_IXGBE(PCI_VENDOR_ID_INTEL,
> IXGBE_DEV_ID_X550EM_X_KR)
> RTE_PCI_DEV_ID_DECL_IXGBE(PCI_VENDOR_ID_INTEL,
> IXGBE_DEV_ID_82599_BYPASS) #endif
>
> -/*** Physical I40E devices from i40e_type.h
> */
> -
> -#define I40E_DEV_ID_SFP_XL710 0x1572
> -#define I40E_DEV_ID_QEMU0x1574
> -#define I40E_DEV_ID_KX_B0x1580
> -#define I40E_DEV_ID_KX_C0x1581
> -#
[dpdk-dev] [PATCH] lib/librte_ether: bypass code cleanup
In testpmd code, device id is used directly to check if bypass
is supported. But APP should not know the details of HW, the NIC
specific info should not be exposed here.
This patch adds a new rte API to check if bypass is supported.
Signed-off-by: Wenzhuo Lu
---
app/test-pmd/cmdline.c | 10 +-
drivers/net/ixgbe/ixgbe_bypass.c | 9 +
drivers/net/ixgbe/ixgbe_bypass.h | 1 +
drivers/net/ixgbe/ixgbe_ethdev.c | 1 +
lib/librte_ether/rte_ethdev.c| 11 +++
lib/librte_ether/rte_ethdev.h| 16 +++-
6 files changed, 38 insertions(+), 10 deletions(-)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index b6b61ad..eb57329 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -10802,22 +10802,14 @@ cmd_reconfig_device_queue(portid_t id, uint8_t dev,
uint8_t queue)
}
#ifdef RTE_NIC_BYPASS
-#include
uint8_t
bypass_is_supported(portid_t port_id)
{
- struct rte_port *port;
- struct rte_pci_id *pci_id;
-
if (port_id_is_invalid(port_id, ENABLED_WARN))
return 0;
- /* Get the device id. */
- port= &ports[port_id];
- pci_id = &port->dev_info.pci_dev->id;
-
/* Check if NIC supports bypass. */
- if (pci_id->device_id == IXGBE_DEV_ID_82599_BYPASS) {
+ if (rte_eth_dev_bypass_supported(port_id)) {
return 1;
}
else {
diff --git a/drivers/net/ixgbe/ixgbe_bypass.c b/drivers/net/ixgbe/ixgbe_bypass.c
index 7006928..6142083 100644
--- a/drivers/net/ixgbe/ixgbe_bypass.c
+++ b/drivers/net/ixgbe/ixgbe_bypass.c
@@ -412,3 +412,12 @@ ixgbe_bypass_wd_reset(struct rte_eth_dev *dev)
return ret_val;
}
+
+s32
+ixgbe_bypass_supported(struct rte_eth_dev *dev)
+{
+ if (dev->pci_dev->id.device_id == IXGBE_DEV_ID_82599_BYPASS)
+ return 0;
+ else
+ return -ENOTSUP;
+}
diff --git a/drivers/net/ixgbe/ixgbe_bypass.h b/drivers/net/ixgbe/ixgbe_bypass.h
index 5f5c63e..787ae61 100644
--- a/drivers/net/ixgbe/ixgbe_bypass.h
+++ b/drivers/net/ixgbe/ixgbe_bypass.h
@@ -50,6 +50,7 @@ struct ixgbe_bypass_info {
struct rte_eth_dev;
+s32 ixgbe_bypass_supported(struct rte_eth_dev *dev);
void ixgbe_bypass_init(struct rte_eth_dev *dev);
s32 ixgbe_bypass_state_show(struct rte_eth_dev *dev, u32 *state);
s32 ixgbe_bypass_state_store(struct rte_eth_dev *dev, u32 *new_state);
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index d478a15..7b7b4ee 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -518,6 +518,7 @@ static const struct eth_dev_ops ixgbe_eth_dev_ops = {
.reta_update = ixgbe_dev_rss_reta_update,
.reta_query = ixgbe_dev_rss_reta_query,
#ifdef RTE_NIC_BYPASS
+ .bypass_supported = ixgbe_bypass_supported,
.bypass_init = ixgbe_bypass_init,
.bypass_state_set = ixgbe_bypass_state_store,
.bypass_state_show= ixgbe_bypass_state_show,
diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index 0a6e3f1..c2e7ff0 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -2827,6 +2827,17 @@ rte_eth_dev_rx_intr_disable(uint8_t port_id,
}
#ifdef RTE_NIC_BYPASS
+int rte_eth_dev_bypass_supported(uint8_t port_id)
+{
+ struct rte_eth_dev *dev;
+
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
+
+ dev = &rte_eth_devices[port_id];
+ RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->bypass_supported, -ENOTSUP);
+ return (*dev->dev_ops->bypass_supported)(dev);
+}
+
int rte_eth_dev_bypass_init(uint8_t port_id)
{
struct rte_eth_dev *dev;
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index 4dac364..45a035a 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -1390,6 +1390,7 @@ enum {
((x) == RTE_BYPASS_TMT_OFF || \
((x) > RTE_BYPASS_TMT_OFF && (x) < RTE_BYPASS_TMT_NUM))
+typedef int32_t (*bypass_supported_t)(struct rte_eth_dev *dev);
typedef void (*bypass_init_t)(struct rte_eth_dev *dev);
typedef int32_t (*bypass_state_set_t)(struct rte_eth_dev *dev, uint32_t
*new_state);
typedef int32_t (*bypass_state_show_t)(struct rte_eth_dev *dev, uint32_t
*state);
@@ -1494,6 +1495,7 @@ struct eth_dev_ops {
/**< Set eeprom */
/* bypass control */
#ifdef RTE_NIC_BYPASS
+ bypass_supported_t bypass_supported;
bypass_init_t bypass_init;
bypass_state_set_t bypass_state_set;
bypass_state_show_t bypass_state_show;
@@ -3576,8 +3578,20 @@ int rte_eth_set_vf_rate_limit(uint8_t port_id, uint16_t
vf,
uint16_t tx_rate, uint64_t q_msk);
/**
+ * Check if the bypass functions is supported by a specific device.
+ *
+ * @param port
+ * The port identifier of the Ethernet device.
+ * @return
+ * - (0) if supported.
+ * - (-ENOTSUP) if hardware doesn't support.
+ * - (-EINVAL) if bad parameter.
+
[dpdk-dev] [PATCH] i40e: move PCI device ids to driver
Hi Helin, 2016-07-11 06:19, Zhang, Helin: > Hi Jingjing > > I'd suggest to add a new header file in each PMD to define what we defined in > rte_pci_dev_ids.h. Why? > There was a patch set submitted several months ago, like that. Which one?
[dpdk-dev] [PATCH] i40e: move PCI device ids to driver
Hi Thomas It should be the one from David as I read that before. I am not sure if all PMD has its own header files for device IDs, but I did see there was. Even in recent kernel drivers (e.g. i40e), there is a new header file for device ID list. I think it could be clearer, though no correct or wrong. Regards, Helin > -Original Message- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Monday, July 11, 2016 2:55 PM > To: Zhang, Helin > Cc: Wu, Jingjing; dev at dpdk.org > Subject: Re: [PATCH] i40e: move PCI device ids to driver > > Hi Helin, > > 2016-07-11 06:19, Zhang, Helin: > > Hi Jingjing > > > > I'd suggest to add a new header file in each PMD to define what we defined > in rte_pci_dev_ids.h. > > Why? > > > There was a patch set submitted several months ago, like that. > > Which one?
[dpdk-dev] [PATCH] lib/librte_ether: bypass code cleanup
2016-07-11 14:21, Wenzhuo Lu: > In testpmd code, device id is used directly to check if bypass > is supported. But APP should not know the details of HW, the NIC > specific info should not be exposed here. Right > This patch adds a new rte API to check if bypass is supported. Hmmm. It's true it is cleaner. But I am not sure having a generic API for bypass is a good idea at all. I was thinking to totally remove it. Maybe we can try to have a specific API by including ixgbe_bypass.h in the application.
[dpdk-dev] [PATCH] i40e: move PCI device ids to driver
Hi, helin What I did is exactly same as what David's patch set did in i40e. I agree with his change. About the new header file, there is already i40e_devids.h in base code which defines the device IDs and vendor ID. This patch just combines them to be a pci device id in struct pci_id_i40e_map in source file. So I don't think a new header file is required. And about kernel driver, I checked it and it did in the similar way. Thanks Jingjing > -Original Message- > From: Zhang, Helin > Sent: Monday, July 11, 2016 3:02 PM > To: Thomas Monjalon > Cc: Wu, Jingjing; dev at dpdk.org > Subject: RE: [PATCH] i40e: move PCI device ids to driver > > Hi Thomas > > It should be the one from David as I read that before. I am not sure if all > PMD > has its own header files for device IDs, but I did see there was. > Even in recent kernel drivers (e.g. i40e), there is a new header file for > device > ID list. I think it could be clearer, though no correct or wrong. > > Regards, > Helin > > > -Original Message- > > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > > Sent: Monday, July 11, 2016 2:55 PM > > To: Zhang, Helin > > Cc: Wu, Jingjing; dev at dpdk.org > > Subject: Re: [PATCH] i40e: move PCI device ids to driver > > > > Hi Helin, > > > > 2016-07-11 06:19, Zhang, Helin: > > > Hi Jingjing > > > > > > I'd suggest to add a new header file in each PMD to define what we > defined > > in rte_pci_dev_ids.h. > > > > Why? > > > > > There was a patch set submitted several months ago, like that. > > > > Which one?
[dpdk-dev] [PATCH] lib/librte_ether: bypass code cleanup
Hi, Wenzhuo I don't think you need to create a new API: rte_eth_dev_bypass_supported. If bypass in not supported, the Ops for bypass feature will not be implemented in driver, or driver need to return NOT supported. So I think what you need do is just remove the NIC specific things from testpmd, including "bypass_is_supported". Thanks Jingjing > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Wenzhuo Lu > Sent: Monday, July 11, 2016 2:21 PM > To: dev at dpdk.org > Cc: thomas.monjalon at 6wind.com; Lu, Wenzhuo > Subject: [dpdk-dev] [PATCH] lib/librte_ether: bypass code cleanup > > In testpmd code, device id is used directly to check if bypass is supported. > But APP should not know the details of HW, the NIC specific info should not > be exposed here. > This patch adds a new rte API to check if bypass is supported. > > Signed-off-by: Wenzhuo Lu
[dpdk-dev] [PATCH] lib/librte_ether: bypass code cleanup
> -Original Message- > From: Wu, Jingjing > Sent: Monday, July 11, 2016 3:51 PM > To: Lu, Wenzhuo; dev at dpdk.org > Cc: thomas.monjalon at 6wind.com; Lu, Wenzhuo > Subject: RE: [dpdk-dev] [PATCH] lib/librte_ether: bypass code cleanup > > Hi, Wenzhuo > > I don't think you need to create a new API: rte_eth_dev_bypass_supported. > If bypass in not supported, the Ops for bypass feature will not be > implemented in > driver, or driver need to return NOT supported. > > So I think what you need do is just remove the NIC specific things from > testpmd, > including "bypass_is_supported". Agree, thanks for the comments!
[dpdk-dev] [PATCH] lib/librte_ether: bypass code cleanup
> -Original Message- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Monday, July 11, 2016 3:11 PM > To: Lu, Wenzhuo > Cc: dev at dpdk.org > Subject: Re: [PATCH] lib/librte_ether: bypass code cleanup > > 2016-07-11 14:21, Wenzhuo Lu: > > In testpmd code, device id is used directly to check if bypass is > > supported. But APP should not know the details of HW, the NIC specific > > info should not be exposed here. > > Right > > > This patch adds a new rte API to check if bypass is supported. > > Hmmm. It's true it is cleaner. But I am not sure having a generic API for > bypass is > a good idea at all. > I was thinking to totally remove it. > Maybe we can try to have a specific API by including ixgbe_bypass.h in the > application. According to Jingjing's comments, I think we need not check if bypass is supported. Every API will return fail if it's not supported. I'll send a V2 to remove the bypass_is_supported.
[dpdk-dev] [PATCH] lib/librte_ether: bypass code cleanup
Hi Thomas, > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon > Sent: Monday, July 11, 2016 8:11 AM > To: Lu, Wenzhuo > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH] lib/librte_ether: bypass code cleanup > > 2016-07-11 14:21, Wenzhuo Lu: > > In testpmd code, device id is used directly to check if bypass > > is supported. But APP should not know the details of HW, the NIC > > specific info should not be exposed here. > > Right > > > This patch adds a new rte API to check if bypass is supported. > > Hmmm. It's true it is cleaner. But I am not sure having a generic API > for bypass is a good idea at all. > I was thinking to totally remove it. Why to remove it? As I know there are people who use that functionality. > Maybe we can try to have a specific API by including ixgbe_bypass.h in > the application. Hmm, isn't that what we were trying to get rid of in last few years? HW specific stuff? Konstantin
[dpdk-dev] [PATCH v2] app/testpmd: bypass code cleanup
In testpmd code, device id is used directly to check if bypass
is supported. But APP should not know the details of HW, the NIC
specific info should not be exposed here.
As every bypass API does know if it's supported, no need to check
that at first. So, this patch removes the *bypass_is_supported*.
Suggested-by: Jingjing Wu
Signed-off-by: Wenzhuo Lu
---
app/test-pmd/cmdline.c | 39 ---
1 file changed, 39 deletions(-)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index b6b61ad..f90befc 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -94,10 +94,6 @@ static struct cmdline *testpmd_cl;
static void cmd_reconfig_device_queue(portid_t id, uint8_t dev, uint8_t queue);
-#ifdef RTE_NIC_BYPASS
-uint8_t bypass_is_supported(portid_t port_id);
-#endif
-
/* *** Help command with introduction. *** */
struct cmd_help_brief_result {
cmdline_fixed_string_t help;
@@ -3656,9 +3652,6 @@ cmd_set_bypass_mode_parsed(void *parsed_result,
portid_t port_id = res->port_id;
uint32_t bypass_mode = RTE_BYPASS_MODE_NORMAL;
- if (!bypass_is_supported(port_id))
- return;
-
if (!strcmp(res->value, "bypass"))
bypass_mode = RTE_BYPASS_MODE_BYPASS;
else if (!strcmp(res->value, "isolate"))
@@ -3725,9 +3718,6 @@ cmd_set_bypass_event_parsed(void *parsed_result,
uint32_t bypass_event = RTE_BYPASS_EVENT_NONE;
uint32_t bypass_mode = RTE_BYPASS_MODE_NORMAL;
- if (!bypass_is_supported(port_id))
- return;
-
if (!strcmp(res->event_value, "timeout"))
bypass_event = RTE_BYPASS_EVENT_TIMEOUT;
else if (!strcmp(res->event_value, "os_on"))
@@ -3903,9 +3893,6 @@ cmd_show_bypass_config_parsed(void *parsed_result,
"timeout"};
int num_events = (sizeof events) / (sizeof events[0]);
- if (!bypass_is_supported(port_id))
- return;
-
/* Display the bypass mode.*/
if (0 != rte_eth_dev_bypass_state_show(port_id, &bypass_mode)) {
printf("\tFailed to get bypass mode for port = %d\n", port_id);
@@ -10800,29 +10787,3 @@ cmd_reconfig_device_queue(portid_t id, uint8_t dev,
uint8_t queue)
ports[id].need_reconfig_queues = queue;
}
}
-
-#ifdef RTE_NIC_BYPASS
-#include
-uint8_t
-bypass_is_supported(portid_t port_id)
-{
- struct rte_port *port;
- struct rte_pci_id *pci_id;
-
- if (port_id_is_invalid(port_id, ENABLED_WARN))
- return 0;
-
- /* Get the device id. */
- port= &ports[port_id];
- pci_id = &port->dev_info.pci_dev->id;
-
- /* Check if NIC supports bypass. */
- if (pci_id->device_id == IXGBE_DEV_ID_82599_BYPASS) {
- return 1;
- }
- else {
- printf("\tBypass not supported for port_id = %d.\n", port_id);
- return 0;
- }
-}
-#endif
--
1.9.3
[dpdk-dev] [PATCH] i40e: move PCI device ids to driver
> -Original Message- > From: Wu, Jingjing > Sent: Monday, July 11, 2016 3:29 PM > To: Zhang, Helin ; Thomas Monjalon > > Cc: dev at dpdk.org > Subject: RE: [PATCH] i40e: move PCI device ids to driver > > Hi, helin > > What I did is exactly same as what David's patch set did in i40e. I agree > with his > change. > About the new header file, there is already i40e_devids.h in base code which > defines the device IDs and vendor ID. This patch just combines them to be a > pci > device id in struct pci_id_i40e_map in source file. So I don't think a new > header > file is required. And about kernel driver, I checked it and it did in the > similar way. OK, I agree with you of that. Thanks! Helin > > Thanks > Jingjing > > > -Original Message- > > From: Zhang, Helin > > Sent: Monday, July 11, 2016 3:02 PM > > To: Thomas Monjalon > > Cc: Wu, Jingjing; dev at dpdk.org > > Subject: RE: [PATCH] i40e: move PCI device ids to driver > > > > Hi Thomas > > > > It should be the one from David as I read that before. I am not sure > > if all PMD has its own header files for device IDs, but I did see there was. > > Even in recent kernel drivers (e.g. i40e), there is a new header file > > for device ID list. I think it could be clearer, though no correct or wrong. > > > > Regards, > > Helin > > > > > -Original Message- > > > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > > > Sent: Monday, July 11, 2016 2:55 PM > > > To: Zhang, Helin > > > Cc: Wu, Jingjing; dev at dpdk.org > > > Subject: Re: [PATCH] i40e: move PCI device ids to driver > > > > > > Hi Helin, > > > > > > 2016-07-11 06:19, Zhang, Helin: > > > > Hi Jingjing > > > > > > > > I'd suggest to add a new header file in each PMD to define what we > > defined > > > in rte_pci_dev_ids.h. > > > > > > Why? > > > > > > > There was a patch set submitted several months ago, like that. > > > > > > Which one?
[dpdk-dev] [PATCH] vhost: fix segfault on bad descriptor address.
On Sun, Jul 10, 2016 at 09:17:31PM +0800, Yuanhan Liu wrote: > On Fri, Jul 08, 2016 at 02:48:56PM +0300, Ilya Maximets wrote: > > > > Another point is that crash constantly happens on queue_id=3 (second RX > > queue) in > > my scenario. It is newly allocated virtqueue while reconfiguration from > > rxq=1 to > > rxq=2. > > That's a valuable message: what's your DPDK HEAD commit while triggering > this issue? I guess I have understood what goes wrong in you case. I would guess that your vhost has 2 queues (here I mean queue-pairs, including one Tx and Rx queue; below usage is the same) configured, so does to your QEMU. However, you just enabled 1 queue while starting testpmd inside the guest, and you want to enable 2 queues by running following testpmd commands: stop port stop all port config all rxq 2 port config all txq 2 port start all Badly, that won't work for current virtio PMD implementation, and what's worse, it triggers a vhost crash, the one you saw. Here is how it comes. Since you just enabled 1 queue while starting testpmd, it will setup 1 queue only, meaning only one queue's **valid** information will be sent to vhost. You might see SET_VRING_ADDR (and related vhost messages) for the other queue as well, but they are just the dummy messages: they don't include any valid/real information about the 2nd queue: the driver don't setup it after all. So far, so good. It became broken when you run above commands. Those commands do setup for the 2nd queue, however, they failed to trigger the QEMU virtio device to start the vhost-user negotiation, meaning no SET_VRING_ADDR will be sent for the 2nd queue, leaving vhost untold and not updated. What's worse, above commands trigger the QEMU to send SET_VRING_ENABLE messages, to enable all the vrings. And since the vrings for the 2nd queue are not properly configured, the crash happens. So maybe we should do virtio reset on port start? --yliu
[dpdk-dev] Ignoring number of bytes read in eal
On 11/07/2016 05:48, David Marchand wrote: > Hello, > > On Tue, Jun 28, 2016 at 10:40 AM, Kobylinski, MichalX > wrote: >> CID 13212 - Ignoring number of bytes read: >> The number of bytes copied into the buffer can be smaller than the requested >> number and the buffer can potentially be accessed out of range. >> In rte_mem_virt2phy: Value returned from a function and indicating the >> number of bytes read is ignored. >> >> File: /lib/librte_eal/linuxapp/eal/eal_memory.c >> Line: 187 >> >> Can I mark this error as "False Positive"? >> >> Because return from read function is checked in "if" condition. If return >> from read is less than 0 function rte_mem_virt2phy is aborted and return: >> log message, RTE_BAD_PHYS_ADDR. > ? > > Coverity is complaining because (in theory) read can return less than > sizeof(uint64_t). > This most likely can't happen, but still coverity is right from my pov. > > I'd rather fix this than mark this as false positive, Sergio ? I agree with David, let's fix this. Sergio
[dpdk-dev] [PATCH v2 0/6] enable lpm, acl and other missing libraries in ppc64le
Gowrishankar, Nice patches! Do you have some function test result? I need some time to verify the patches. -Original Message- From: Gowrishankar [mailto:gowrishanka...@linux.vnet.ibm.com] Sent: 2016?7?10? 15:51 To: dev at dpdk.org Cc: Chao Zhu ; Bruce Richardson ; Konstantin Ananyev ; Thomas Monjalon ; Cristian Dumitrescu ; Pradeep ; gowrishankar Subject: [PATCH v2 0/6] enable lpm, acl and other missing libraries in ppc64le From: gowrishankar This patchset enables LPM, ACL and other few missing libs in ppc64le and also address few patches in related examples (ip_pipeline and l3fwd). Test report: LPM and ACL unit tests verified as in patch set v1. Same results as before observed. v2 changes: - enabling libs in config included as part of lib changes itself. gowrishankar (6): lpm: add altivec intrinsics for dpdk lpm on ppc_64 acl: add altivec intrinsics for dpdk acl on ppc_64 ip_pipeline: fix lcore mapping for varying SMT threads as in ppc64 table: cache align rte_bucket_4_8 sched: enable sched library for ppc64le l3fwd: add altivec support for em_hash_key app/test-acl/main.c| 4 + app/test/test_xmmt_ops.h | 16 + config/defconfig_ppc_64-power8-linuxapp-gcc| 7 - examples/ip_pipeline/cpu_core_map.c| 12 +- examples/ip_pipeline/init.c| 4 + examples/l3fwd/l3fwd_em.c | 8 + lib/librte_acl/Makefile| 2 + lib/librte_acl/acl.h | 4 + lib/librte_acl/acl_run.h | 2 + lib/librte_acl/acl_run_altivec.c | 47 +++ lib/librte_acl/acl_run_altivec.h | 328 + lib/librte_acl/rte_acl.c | 13 + lib/librte_acl/rte_acl.h | 1 + .../common/include/arch/ppc_64/rte_vect.h | 60 lib/librte_lpm/Makefile| 2 + lib/librte_lpm/rte_lpm.h | 2 + lib/librte_lpm/rte_lpm_altivec.h | 154 ++ lib/librte_table/rte_table_hash_key8.c | 2 +- 18 files changed, 649 insertions(+), 19 deletions(-) create mode 100644 lib/librte_acl/acl_run_altivec.c create mode 100644 lib/librte_acl/acl_run_altivec.h create mode 100644 lib/librte_eal/common/include/arch/ppc_64/rte_vect.h create mode 100644 lib/librte_lpm/rte_lpm_altivec.h -- 1.9.1
[dpdk-dev] [PATCH] lib/librte_ether: bypass code cleanup
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon > > Hmmm. It's true it is cleaner. But I am not sure having a generic API > > for bypass is a good idea at all. > > I was thinking to totally remove it. > > Why to remove it? > As I know there are people who use that functionality. > > > Maybe we can try to have a specific API by including ixgbe_bypass.h in > > the application. > > Hmm, isn't that what we were trying to get rid of in last few years? > HW specific stuff? Yes exactly. I have the feeling the bypass API is specific to ixgbe. Isn't it? As we will probably see other features specific to only one device. Instead of adding a function in the generic API, I think it may be saner to include a driver header. Then if it appears to be used in more devices, it can be generalized. What do you think of this approach?
[dpdk-dev] [PATCH] vhost: fix segfault on bad descriptor address.
On 11.07.2016 11:38, Yuanhan Liu wrote:
> On Sun, Jul 10, 2016 at 09:17:31PM +0800, Yuanhan Liu wrote:
>> On Fri, Jul 08, 2016 at 02:48:56PM +0300, Ilya Maximets wrote:
>>>
>>> Another point is that crash constantly happens on queue_id=3 (second RX
>>> queue) in
>>> my scenario. It is newly allocated virtqueue while reconfiguration from
>>> rxq=1 to
>>> rxq=2.
>>
>> That's a valuable message: what's your DPDK HEAD commit while triggering
>> this issue?
fbfd99551ca3 ("mbuf: add raw allocation function")
>
> I guess I have understood what goes wrong in you case.
>
> I would guess that your vhost has 2 queues (here I mean queue-pairs,
> including one Tx and Rx queue; below usage is the same) configured,
> so does to your QEMU. However, you just enabled 1 queue while starting
> testpmd inside the guest, and you want to enable 2 queues by running
> following testpmd commands:
>
> stop
> port stop all
> port config all rxq 2
> port config all txq 2
> port start all
>
> Badly, that won't work for current virtio PMD implementation, and what's
> worse, it triggers a vhost crash, the one you saw.
>
> Here is how it comes. Since you just enabled 1 queue while starting
> testpmd, it will setup 1 queue only, meaning only one queue's **valid**
> information will be sent to vhost. You might see SET_VRING_ADDR
> (and related vhost messages) for the other queue as well, but they
> are just the dummy messages: they don't include any valid/real
> information about the 2nd queue: the driver don't setup it after all.
>
> So far, so good. It became broken when you run above commands. Those
> commands do setup for the 2nd queue, however, they failed to trigger
> the QEMU virtio device to start the vhost-user negotiation, meaning
> no SET_VRING_ADDR will be sent for the 2nd queue, leaving vhost
> untold and not updated.
>
> What's worse, above commands trigger the QEMU to send SET_VRING_ENABLE
> messages, to enable all the vrings. And since the vrings for the 2nd
> queue are not properly configured, the crash happens.
Hmm, why 2nd queue works properly with my fix to vhost in this case?
> So maybe we should do virtio reset on port start?
I guess it was removed by this patch:
a85786dc816f ("virtio: fix states handling during initialization").
[dpdk-dev] [PATCH v2 0/6] enable lpm, acl and other missing libraries in ppc64le
Hi Chao, On Monday 11 July 2016 02:25 PM, Chao Zhu wrote: > Gowrishankar, > > Nice patches! Do you have some function test result? I need some time to > verify the patches. Please find below lpm and acl units tests (Test OK at the end of each tests). # ./app/test < EAL/PMD logs> APP: HPET is not enabled, using TSC as default timer RTE>>lpm_autotest No. routes = 1076806 Route distribution per prefix width: DEPTHQUANTITY (PERCENT) --- 01 0 (0.00) 02 0 (0.00) 03 1 (0.00) 04 0 (0.00) 05 3 (0.00) 06 2 (0.00) 07 4 (0.00) 08201 (0.02) 09 37 (0.00) 10 55 (0.01) 11 97 (0.01) 12381 (0.04) 13775 (0.07) 14 2104 (0.20) 15 3712 (0.34) 16 69319 (6.44) 17 12983 (1.21) 18 23667 (2.20) 19 69068 (6.41) 20 62354 (5.79) 21 48531 (4.51) 22 72355 (6.72) 23 85427 (7.93) 24 583900 (54.23) 25 2654 (0.25) 26 5650 (0.52) 27 6467 (0.60) 28 7127 (0.66) 29 12936 (1.20) 30 5999 (0.56) 31 13 (0.00) 32984 (0.09) Unique added entries = 1039948 Used table 24 entries = 11343198 (67.6107%) 64 byte Cache entries used = 360735 (23087040 bytes) Average LPM Add: 110820 cycles Average LPM Lookup: 34.5 cycles (fails = 19.3%) BULK LPM Lookup: 31.5 cycles (fails = 19.3%) LPM LookupX4: 29.5 cycles (fails = 19.3%) Average LPM Delete: 63841.6 cycles Test OK RTE>>acl_autotest ACL: allocation of 25166728 bytes on socket 33 for ACL_acl_ctx failed ACL: rte_acl_add_rules(acl_ctx): rule #1 is invalid ACL: rte_acl_ipv4vlan_add_rules: rule #1 is invalid ACL: rte_acl_ipv4vlan_add_rules: rule #1 is invalid ACL: rte_acl_ipv4vlan_add_rules: rule #1 is invalid ACL: rte_acl_ipv4vlan_add_rules: rule #1 is invalid ACL: rte_acl_add_rules(acl_ctx): rule #1 is invalid ACL: Gen phase for ACL "acl_ctx": runtime memory footprint on socket -1: single nodes/bytes used: 0/0 quad nodes/vectors/bytes used: 0/0/0 DFA nodes/group64/bytes used: 1/4/4104 match nodes/bytes used: 1/128 total: 6432 bytes max limit: 18446744073709551615 bytes ACL: Build phase for ACL "acl_ctx": node limit for tree split: 2048 nodes created: 2 memory consumed: 8388615 ACL: trie 0: number of rules: 16, indexes: 1 ACL: Gen phase for ACL "acl_ctx": runtime memory footprint on socket -1: single nodes/bytes used: 22/176 quad nodes/vectors/bytes used: 30/104/832 DFA nodes/group64/bytes used: 6/19/11784 match nodes/bytes used: 6/768 total: 15760 bytes max limit: 18446744073709551615 bytes ACL: Build phase for ACL "acl_ctx": node limit for tree split: 2048 nodes created: 64 memory consumed: 8388615 ACL: trie 0: number of rules: 6000, indexes: 4 acl context @0x3efded3b3400 socket_id=-1 alg=5 max_rules=196608 rule_size=128 num_rules=0 num_categories=0 num_tries=0 acl context @0x3efded3b3400 socket_id=-1 alg=5 max_rules=196608 rule_size=128 num_rules=0 num_categories=0 num_tries=0 ACL: Gen phase for ACL "acl_ctx": runtime memory footprint on socket -1: single nodes/bytes used: 974/7792 quad nodes/vectors/bytes used: 816/3211/25688 DFA nodes/group64/bytes used: 137/289/150024 match nodes/bytes used: 1181/151168 total: 336880 bytes max limit: 18446744073709551615 bytes ACL: Build phase for ACL "acl_ctx": node limit for tree split: 2048 nodes created: 3108 memory consumed: 8388615 ACL: trie 0: number of rules: 15, indexes: 4 ACL: trie 1: number of rules: 12, indexes: 5 ACL: Gen phase for ACL "acl_ctx": runtime memory footprint on socket -1: single nodes/bytes used: 974/7792 quad nodes/vectors/bytes used: 816/3211/25688 DFA nodes/group64/bytes used: 137/289/150024 match nodes/bytes used: 1181/151168 total: 336880 bytes max limit: 18446744073709551615 bytes ACL: Build phase for ACL "acl_ctx": node limit for tree split: 2048 nodes created: 3108 memory consumed: 8388615 ACL: trie 0: number of rules: 15, indexes: 4 ACL: trie 1: number of rules: 12, indexes: 5 ACL: Build phase for ACL "acl_ctx": node limit for tree split: 2048 nodes created: 0 memory consumed: 8388615 ACL: Gen phase for ACL "acl_ctx": runtime memory footprint on socket -1: single nodes/bytes used: 974/7792 quad nodes/vectors/bytes used: 816/3211/25688 DFA nodes/group64/bytes used: 137/289/150024 match nodes/bytes used: 1181/151168 total: 336880 bytes max limit: 18446744073709551615 bytes ACL: Build phase for ACL "acl_ctx": node limit for tree split: 2048 nodes created: 3108 memory consumed: 8388615 ACL: trie 0: number of rules: 15, indexes: 4 ACL: trie 1: number of rules: 12, indexes: 5 ACL: Gen phase for ACL "acl_ctx": runtime memory footprint on socket -1: single nodes/bytes used: 974/7792 quad nodes/vectors/bytes used: 816/3211/25688 DFA nodes/group64/bytes used: 137/289/150024 match nodes/bytes used: 1181/151168 total: 336880 bytes max limi
[dpdk-dev] [PATCH] lib/librte_ether: bypass code cleanup
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon > > > Hmmm. It's true it is cleaner. But I am not sure having a generic API > > > for bypass is a good idea at all. > > > I was thinking to totally remove it. > > > > Why to remove it? > > As I know there are people who use that functionality. > > > > > Maybe we can try to have a specific API by including ixgbe_bypass.h in > > > the application. > > > > Hmm, isn't that what we were trying to get rid of in last few years? > > HW specific stuff? > > Yes exactly. > I have the feeling the bypass API is specific to ixgbe. Isn't it? As far as I know, yes. > > As we will probably see other features specific to only one device. > Instead of adding a function in the generic API, I think it may be > saner to include a driver header. But that means use has to make decision based on HW id/type of the device, the thing we were trying to get rid of in last few releases, no? > Then if it appears to be used > in more devices, it can be generalized. > What do you think of this approach? We talked few times about introducing sort of ioctl() call, to communicate about HW specific features. Might be a bypass I a good candidate to be moved into this ioctl() thing... But I suppose it's too late for 16.07 to start such big changes. If you don't like bypass API to be a generic one, my suggestion would be to leave it as it is for 16.07, and start a discussion what it should look like for 16.11. Konstantin
[dpdk-dev] [PATCH] net/enic: decrement Tx mbuf reference count before recycling
Hi John,
On 07/09/2016 12:22 AM, John Daley wrote:
> In the Tx cleanup function, the reference count in mbufs to be
> returned to the pool should to be decremented before they are
> returned. Decrementing is not done by rte_mempool_put_bulk()
> so it must be done separately using __rte_pktmbuf_prefree_seg().
> If decrementing does not result in a 0 reference count the mbuf
> is not returned to the pool and whatever has the last reference
> is responsible for freeing.
>
> Fixes: 36935afbc53c ("net/enic: refactor Tx mbuf recycling")
> Reviewed-by: Nelson Escobar
> Signed-off-by: John Daley
> ---
> Since reference counts are set to 0 when mbufs are reallocated from the
> pool, and sending packets with reference count not equal to 1 is probably
> an application error, this patch may not be critical. But a debug ASSERT
> caught it and it would be nice to have it fixed in 16.07.
Sending a packet with refcnt != 1 is not an error. It can happen when
using mbuf clones. So indeed it would be better to have in 16.07.
For the same reason, I also wonder if enic_free_wq_buf() should also be
updated with:
- rte_mempool_put(mbuf->pool, mbuf);
+ rte_pktmbuf_free(mbuf);
Regards,
Olivier
[dpdk-dev] [RFC] Generic flow director/filtering/classification API
On Mon, Jul 11, 2016 at 03:18:19AM +, Liang, Cunming wrote:
[...]
> > > >When several actions are combined in a flow rule, they should all have
> > > >different types (e.g. dropping a packet twice is not possible). However
> > > >considering the VOID type is an exception to this rule, the defined
> > > >behavior
> > > >is for PMDs to only take into account the last action of a given type
> > > >found
> > > >in the list. PMDs still perform error checking on the entire list.
> > > >
> > > >*Note that PASSTHRU is the only action able to override a terminating
> > > >rule.*
> > > [LC] I'm wondering how to address the meta data carried by mbuf, there's
> > > no
> > > mentioned here.
> > > For packets hit one specific flow, usually there's something for CPU to
> > > identify the flow.
> > > FDIR and RSS as an example, has id or key in mbuf. In addition, some meta
> > > may pointed by userdata in mbuf.
> > > Any view on it ?
> >
> > Yes, this is defined as the ID action. It is described in 4.1.6.4 (ID) and
> > there is an example how a FDIR rule would be converted to use it in 5.7
> > (FDIR to most item types ? QUEUE, DROP, PASSTHRU).
> [LC] So in RSS cases, the actions would be {RSS, ID}, in which ID represent
> for RSS key, right?
Well, the ID action is always the same regardless of other actions, it
takes an arbitrary 32 bit value to be returned back as meta data with
matched packets, no side effect on RSS is expected.
If you are talking about the RSS action (4.1.6.9), RSS configuration (key
and algorithm to use) are provided in their specific structure along with
the list of target queues (see struct rte_flow_action_rss in [1]).
Note the RSS action is independent, it is unrelated to the port-wide RSS
configuration. Devices may not be able to support both simultaneously, for
instance creating multiple queues with RSS enabled globally may prevent
requesting a flow rule with a RSS action later. Likewise, such a rule may
possibly be defined only once depending on capabilities.
For devices supporting both, think of it as multiple level RSS. Flow rules
perform RSS on selected packets first, then the default global RSS
configuration takes care of packets that haven't hit a terminating flow
rule. This is the same as the QUEUE action except RSS is additionally
performed to spread packet among several queues.
Thus applications can request RSS with ID to get both RSS _and_ their
arbitrary 32 bit value as meta data. Once again, HW support for this
combination is not mandatory.
PMDs can assist HW to work around such limitations sometimes as described in
4.4.4 (Unsupported actions) as long as the software cost is kept minimal.
[1] https://raw.githubusercontent.com/6WIND/rte_flow/master/rte_flow.h
--
Adrien Mazarguil
6WIND
[dpdk-dev] specific driver API - was bypass code cleanup
2016-07-11 09:56, Ananyev, Konstantin: > > > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon > > > > Hmmm. It's true it is cleaner. But I am not sure having a generic API > > > > for bypass is a good idea at all. > > > > I was thinking to totally remove it. > > > > > > Why to remove it? > > > As I know there are people who use that functionality. > > > > > > > Maybe we can try to have a specific API by including ixgbe_bypass.h in > > > > the application. > > > > > > Hmm, isn't that what we were trying to get rid of in last few years? > > > HW specific stuff? > > > > Yes exactly. > > I have the feeling the bypass API is specific to ixgbe. Isn't it? > > As far as I know, yes. > > > As we will probably see other features specific to only one device. > > Instead of adding a function in the generic API, I think it may be > > saner to include a driver header. > > But that means use has to make decision based on HW id/type of the device, > the thing we were trying to get rid of in last few releases, no? Not really. If an application requires the bypass feature, we can assume it will be used only on ixgbe NICs. Having some generic APIs helps to deploy DPDK applications on heterogeous machines. But if an application rely on something hardware specific, there is no benefit of using a "fake generic layer" I guess. > > Then if it appears to be used > > in more devices, it can be generalized. > > What do you think of this approach? > > We talked few times about introducing sort of ioctl() call, to communicate > about HW specific features. > Might be a bypass I a good candidate to be moved into this ioctl() thing... I don't see how making an ioctl-like would be better than directly including a specific header. > But I suppose it's too late for 16.07 to start such big changes. Of course yes. > If you don't like bypass API to be a generic one, my suggestion would be > to leave it as it is for 16.07, and start a discussion what it should look > like > for 16.11. That's what we are doing here. I've changed the title to give a better visibility to the thread.
[dpdk-dev] [PATCH 0/4] fix mempool creation with Xen Dom0
Since the recent mempool rework [1], Xen Dom0 is broken. This series aims at fixing it. I think it should be integrated in 16.07. As I don't have a full testing platform, any help in validating this patchset would be appreciated. [1] http://www.dpdk.org/ml/archives/dev/2016-May/039229.html Olivier Matz (4): eal: fix typo in Xen Dom0 specific code mbuf: set errno on pool creation error eal: fix retrieval of phys address with Xen Dom0 mempool: fix creation with Xen Dom0 lib/librte_eal/linuxapp/eal/eal_memory.c | 23 +++ lib/librte_eal/linuxapp/eal/eal_xen_memory.c | 4 ++-- lib/librte_mbuf/rte_mbuf.c | 5 - lib/librte_mempool/rte_mempool.c | 6 +- 4 files changed, 34 insertions(+), 4 deletions(-) -- 2.8.1
[dpdk-dev] [PATCH 1/4] eal: fix typo in Xen Dom0 specific code
Fix the compilation with CONFIG_RTE_LIBRTE_XEN_DOM0=y, by correcting the
typo in variable names.
Fixes: 8dab48370129 ("xen: return machine address without knowing memseg id")
Signed-off-by: Olivier Matz
---
lib/librte_eal/linuxapp/eal/eal_xen_memory.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/librte_eal/linuxapp/eal/eal_xen_memory.c
b/lib/librte_eal/linuxapp/eal/eal_xen_memory.c
index 0b612bb..bddbdb0 100644
--- a/lib/librte_eal/linuxapp/eal/eal_xen_memory.c
+++ b/lib/librte_eal/linuxapp/eal/eal_xen_memory.c
@@ -167,8 +167,8 @@ rte_xen_mem_phy2mch(int32_t memseg_id, const phys_addr_t
phy_addr)
if (memseg_id == -1) {
for (i = 0; i < RTE_MAX_MEMSEG; i++) {
if ((phy_addr >= memseg[i].phys_addr) &&
- (phys_addr < memseg[i].phys_addr +
- memseg[i].size)) {
+ (phy_addr < memseg[i].phys_addr +
+ memseg[i].len)) {
memseg_id = i;
break;
}
--
2.8.1
[dpdk-dev] [PATCH 2/4] mbuf: set errno on pool creation error
In rte_pktmbuf_pool_create(), the rte_errno variable was not always
set on failure.
Fixes: 152ca517900b ("mbuf: use default mempool handler from config")
Signed-off-by: Olivier Matz
---
lib/librte_mbuf/rte_mbuf.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/lib/librte_mbuf/rte_mbuf.c b/lib/librte_mbuf/rte_mbuf.c
index 601e528..4846b89 100644
--- a/lib/librte_mbuf/rte_mbuf.c
+++ b/lib/librte_mbuf/rte_mbuf.c
@@ -156,6 +156,7 @@ rte_pktmbuf_pool_create(const char *name, unsigned n,
struct rte_mempool *mp;
struct rte_pktmbuf_pool_private mbp_priv;
unsigned elt_size;
+ int ret;
if (RTE_ALIGN(priv_size, RTE_MBUF_PRIV_ALIGN) != priv_size) {
RTE_LOG(ERR, MBUF, "mbuf priv_size=%u is not aligned\n",
@@ -181,8 +182,10 @@ rte_pktmbuf_pool_create(const char *name, unsigned n,
}
rte_pktmbuf_pool_init(mp, &mbp_priv);
- if (rte_mempool_populate_default(mp) < 0) {
+ ret = rte_mempool_populate_default(mp);
+ if (ret < 0) {
rte_mempool_free(mp);
+ rte_errno = -ret;
return NULL;
}
--
2.8.1
[dpdk-dev] [PATCH 3/4] eal: fix retrieval of phys address with Xen Dom0
When using Xen Dom0, it looks that /proc/self/pagemap returns 0.
This breaks the creation of mbufs pool.
We can workaround this in rte_mem_virt2phy() by browsing the dpdk memory
segments. This only works for dpdk memory, but it's enough to fix the
mempool creation.
Fixes: c042ba20674a ("mempool: rework support of Xen dom0")
Fixes: 3097de6e6bfb ("mem: get physical address of any pointer")
Signed-off-by: Olivier Matz
---
lib/librte_eal/linuxapp/eal/eal_memory.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/lib/librte_eal/linuxapp/eal/eal_memory.c
b/lib/librte_eal/linuxapp/eal/eal_memory.c
index b663244..42a29fa 100644
--- a/lib/librte_eal/linuxapp/eal/eal_memory.c
+++ b/lib/librte_eal/linuxapp/eal/eal_memory.c
@@ -164,6 +164,29 @@ rte_mem_virt2phy(const void *virtaddr)
int page_size;
off_t offset;
+ /* when using dom0, /proc/self/pagemap always returns 0, check in
+* dpdk memory by browsing the memsegs */
+ if (rte_xen_dom0_supported()) {
+ struct rte_mem_config *mcfg;
+ struct rte_memseg *memseg;
+ unsigned i;
+
+ mcfg = rte_eal_get_configuration()->mem_config;
+ for (i = 0; i < RTE_MAX_MEMSEG; i++) {
+ memseg = &mcfg->memseg[i];
+ if (memseg->addr == NULL)
+ break;
+ if (virtaddr > memseg->addr &&
+ virtaddr < RTE_PTR_ADD(memseg->addr,
+ memseg->len)) {
+ return memseg->phys_addr +
+ RTE_PTR_DIFF(virtaddr, memseg->addr);
+ }
+ }
+
+ return RTE_BAD_PHYS_ADDR;
+ }
+
/* Cannot parse /proc/self/pagemap, no need to log errors everywhere */
if (!proc_pagemap_readable)
return RTE_BAD_PHYS_ADDR;
--
2.8.1
[dpdk-dev] [PATCH 4/4] mempool: fix creation with Xen Dom0
Restore the use of 2M hugepages when using Xen Dom0 that was
dropped during mempool rework.
Fixes: c042ba20674a ("mempool: rework support of Xen dom0")
Signed-off-by: Olivier Matz
---
lib/librte_mempool/rte_mempool.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/lib/librte_mempool/rte_mempool.c b/lib/librte_mempool/rte_mempool.c
index d78d02b..6ec0906 100644
--- a/lib/librte_mempool/rte_mempool.c
+++ b/lib/librte_mempool/rte_mempool.c
@@ -524,7 +524,11 @@ rte_mempool_populate_default(struct rte_mempool *mp)
if (mp->nb_mem_chunks != 0)
return -EEXIST;
- if (rte_eal_has_hugepages()) {
+ if (rte_xen_dom0_supported()) {
+ pg_sz = RTE_PGSIZE_2M;
+ pg_shift = rte_bsf32(pg_sz);
+ align = pg_sz;
+ } else if (rte_eal_has_hugepages()) {
pg_shift = 0; /* not needed, zone is physically contiguous */
pg_sz = 0;
align = RTE_CACHE_LINE_SIZE;
--
2.8.1
[dpdk-dev] [PATCH] lib: move rte_ring read barrier to correct location
Fix the location of the rte_ring data dependency read barrier. It needs to be called before accessing indexed data to ensure that the data itself is guaranteed to be correctly updated. See more details at kernel/Documentation/memory-barriers.txt section 'Data dependency barriers'. Signed-off-by: Juhamatti Kuusisaari --- lib/librte_ring/rte_ring.h | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/lib/librte_ring/rte_ring.h b/lib/librte_ring/rte_ring.h index eb45e41..a923e49 100644 --- a/lib/librte_ring/rte_ring.h +++ b/lib/librte_ring/rte_ring.h @@ -662,9 +662,10 @@ __rte_ring_mc_do_dequeue(struct rte_ring *r, void **obj_table, cons_next); } while (unlikely(success == 0)); + rte_smp_rmb(); + /* copy in table */ DEQUEUE_PTRS(); - rte_smp_rmb(); /* * If there are other dequeues in progress that preceded us, @@ -746,9 +747,10 @@ __rte_ring_sc_do_dequeue(struct rte_ring *r, void **obj_table, cons_next = cons_head + n; r->cons.head = cons_next; + rte_smp_rmb(); + /* copy in table */ DEQUEUE_PTRS(); - rte_smp_rmb(); __RING_STAT_ADD(r, deq_success, n); r->cons.tail = cons_next; -- 2.9.0 The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Coriant-Tellabs
[dpdk-dev] I211, Double VLAN tags and VLAN Stripping not working
Hello, I am using the development branch of DPDK and am trying out double tagging using the DPDK PMD E1000 driver.
[dpdk-dev] specific driver API - was bypass code cleanup
> > > > > Hmmm. It's true it is cleaner. But I am not sure having a generic API > > > > > for bypass is a good idea at all. > > > > > I was thinking to totally remove it. > > > > > > > > Why to remove it? > > > > As I know there are people who use that functionality. > > > > > > > > > Maybe we can try to have a specific API by including ixgbe_bypass.h in > > > > > the application. > > > > > > > > Hmm, isn't that what we were trying to get rid of in last few years? > > > > HW specific stuff? > > > > > > Yes exactly. > > > I have the feeling the bypass API is specific to ixgbe. Isn't it? > > > > As far as I know, yes. > > > > > As we will probably see other features specific to only one device. > > > Instead of adding a function in the generic API, I think it may be > > > saner to include a driver header. > > > > But that means use has to make decision based on HW id/type of the device, > > the thing we were trying to get rid of in last few releases, no? > > Not really. If an application requires the bypass feature, we can assume > it will be used only on ixgbe NICs. Bypass HW doesn't present on all ixgbe devices. Only few specific models have that functionality. So we still to provide and API for user to query is that functionality is supported or not, user still has to make a decision based on HW id. > Having some generic APIs helps to deploy DPDK applications on heterogeous > machines. But if an application rely on something hardware specific, there > is no benefit of using a "fake generic layer" I guess. Ok, what is your definition of 'heterogeous machines' then? Let say today, as I know, only i40e and ixgbe can do HW mirroring of the traffic. Is that generic enough, or not? I suppose we can find huge number of examples, when functionality differes between different HW models. As I remember that was discussed a while ago, and generic conclusion was: avoid device specific API exposed to the application layer. > > > > Then if it appears to be used > > > in more devices, it can be generalized. > > > What do you think of this approach? > > > > We talked few times about introducing sort of ioctl() call, to communicate > > about HW specific features. > > Might be a bypass I a good candidate to be moved into this ioctl() thing... > > I don't see how making an ioctl-like would be better than directly including > a specific header. User and application writer don't have to guess on what device his code will work. He can just query what ioctl IDs that device support, and then use the supported ones. > > > But I suppose it's too late for 16.07 to start such big changes. > > Of course yes. Ok, then I misunderstood you here. > > > If you don't like bypass API to be a generic one, my suggestion would be > > to leave it as it is for 16.07, and start a discussion what it should look > > like > > for 16.11. > > That's what we are doing here. > I've changed the title to give a better visibility to the thread. Ok, thanks. Konstantin
[dpdk-dev] [RFC] Generic flow director/filtering/classification API
On Tue, Jul 05, 2016 at 08:16:46PM +0200, Adrien Mazarguil wrote: Hi Adrien, Overall this proposal looks very good. I could easily map to the classification hardware engines I am familiar with. > Priorities > ~~ > > A priority can be assigned to a matching pattern. > > The default priority level is 0 and is also the highest. Support for more > than a single priority level in hardware is not guaranteed. > > If a packet is matched by several filters at a given priority level, the > outcome is undefined. It can take any path and can even be duplicated. In some cases fatal unrecoverable error too > Matching pattern items for packet data must be naturally stacked (ordered > from lowest to highest protocol layer), as in the following examples: > > +--+ > | TCPv4 as L4 | > +===+==+ > | 0 | Ethernet | > +---+--+ > | 1 | IPv4 | > +---+--+ > | 2 | TCP | > +---+--+ > > ++ > | TCPv6 in VXLAN | > +===++ > | 0 | Ethernet | > +---++ > | 1 | IPv4 | > +---++ > | 2 | UDP| > +---++ > | 3 | VXLAN | > +---++ > | 4 | Ethernet | > +---++ > | 5 | IPv6 | > +---++ How about enumerating as "Inner-IPV6" flow type to avoid any confusion. Though spec can be same for both IPv6 and Inner-IPV6. > | 6 | TCP| > +---++ > > +-+ > | TCPv4 as L4 with meta items | > +===+=+ > | 0 | VOID| > +---+-+ > | 1 | Ethernet| > +---+-+ > | 2 | VOID| > +---+-+ > | 3 | IPv4| > +---+-+ > | 4 | TCP | > +---+-+ > | 5 | VOID| > +---+-+ > | 6 | VOID| > +---+-+ > > The above example shows how meta items do not affect packet data matching > items, as long as those remain stacked properly. The resulting matching > pattern is identical to "TCPv4 as L4". > > ++ > | UDPv6 anywhere | > +===++ > | 0 | IPv6 | > +---++ > | 1 | UDP| > +---++ > > If supported by the PMD, omitting one or several protocol layers at the > bottom of the stack as in the above example (missing an Ethernet > specification) enables hardware to look anywhere in packets. It would be good if the common code can give it as Ethernet, IPV6, UDP to PMD(to avoid common code duplication across PMDs) > > It is unspecified whether the payload of supported encapsulations > (e.g. VXLAN inner packet) is matched by such a pattern, which may apply to > inner, outer or both packets. a separate flow type enumeration may fix that problem. like "Inner-IPV6" mentioned above. > > +-+ > | Invalid, missing L3 | > +===+=+ > | 0 | Ethernet| > +---+-+ > | 1 | UDP | > +---+-+ > > The above pattern is invalid due to a missing L3 specification between L2 > and L4. It is only allowed at the bottom and at the top of the stack. > > ``SIGNATURE`` > ^ > > Requests hash-based signature dispatching for this rule. > > Considering this is a global setting on devices that support it, all > subsequent filter rules may have to be created with it as well. Can you describe the use case for this and how its different from existing rte_eth devel RSS settings. > > - Only ``spec`` needs to be defined, ``mask`` is ignored. > > ++ > | SIGNATURE | > +==+=+ > | ``spec`` | TBD | > +--+-+ > | ``mask`` | ignored | > +--+-+ > > > ``ETH`` > ^^^ > > Matches an Ethernet header. > > - ``dst``: destination MAC. > - ``src``: source MAC. > - ``type``: EtherType. > - ``tags``: number of 802.1Q/ad tags defined. > - ``tag[]``: 802.1Q/ad tag definitions, innermost first. For each one: > > - ``tpid``: Tag protocol identifier. > - ``tci``: Tag control information. Find below the other L2 layer attributes are useful in HW classification, - HiGig headers - DSA Headers - MPLS May be we need to intrdouce a separate flow type with spec to add the support. Right? Jerin
[dpdk-dev] [RFC] Generic flow director/filtering/classification API
Hi Adrien, Thank you for your response, Please see my comments inline. Regards _Sugesh > -Original Message- > From: Adrien Mazarguil [mailto:adrien.mazarguil at 6wind.com] > Sent: Friday, July 8, 2016 2:03 PM > To: Chandran, Sugesh > Cc: dev at dpdk.org; Thomas Monjalon ; > Zhang, Helin ; Wu, Jingjing > ; Rasesh Mody ; Ajit > Khaparde ; Rahul Lakkireddy > ; Lu, Wenzhuo ; > Jan Medala ; John Daley ; Chen, > Jing D ; Ananyev, Konstantin > ; Matej Vido ; > Alejandro Lucero ; Sony Chacko > ; Jerin Jacob > ; De Lara Guarch, Pablo > ; Olga Shern > Subject: Re: [dpdk-dev] [RFC] Generic flow director/filtering/classification > API > > Hi Sugesh, > > On Thu, Jul 07, 2016 at 11:15:07PM +, Chandran, Sugesh wrote: > > Hi Adrien, > > > > Thank you for proposing this. It would be really useful for application such > as OVS-DPDK. > > Please find my comments and questions inline below prefixed with > [Sugesh]. Most of them are from the perspective of enabling these APIs in > application such as OVS-DPDK. > > Thanks, I'm replying below. > > > > -Original Message- > > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Adrien > Mazarguil > > > Sent: Tuesday, July 5, 2016 7:17 PM > > > To: dev at dpdk.org > > > Cc: Thomas Monjalon ; Zhang, Helin > > > ; Wu, Jingjing ; > > > Rasesh > > > Mody ; Ajit Khaparde > > > ; Rahul Lakkireddy > > > ; Lu, Wenzhuo > ; > > > Jan Medala ; John Daley ; > Chen, > > > Jing D ; Ananyev, Konstantin > > > ; Matej Vido ; > > > Alejandro Lucero ; Sony Chacko > > > ; Jerin Jacob > > > ; De Lara Guarch, Pablo > > > ; Olga Shern > > > Subject: [dpdk-dev] [RFC] Generic flow director/filtering/classification > API > > >> > > Flow director > > > - > > > > > > Flow director (FDIR) is the name of the most capable filter type, which > > > covers most features offered by others. As such, it is the most > widespread > > > in PMDs that support filtering (i.e. all of them besides **e1000**). > > > > > > It is also the only type that allows an arbitrary 32 bits value provided > > > by > > > applications to be attached to a filter and returned with matching packets > > > instead of relying on the destination queue to recognize flows. > > > > > > Unfortunately, even FDIR requires applications to be aware of low-level > > > capabilities and limitations (most of which come directly from **ixgbe** > and > > > **i40e**): > > > > > > - Bitmasks are set globally per device (port?), not per filter. > > [Sugesh] This means application cannot define filters that matches on > arbitrary different offsets? > > If that?s the case, I assume the application has to program bitmask in > advance. Otherwise how > > the API framework deduce this bitmask information from the rules?? Its > not very clear to me > > that how application pass down the bitmask information for multiple filters > on same port? > > This is my understanding of how flow director currently works, perhaps > someome more familiar with it can answer this question better than I could. > > Let me take an example, if particular device can only handle a single IPv4 > mask common to all flow rules (say only to match destination addresses), > updating that mask to also match the source address affects all defined and > future flow rules simultaneously. > > That is how FDIR currently works and I think it is wrong, as it penalizes > devices that do support individual bit-masks per rule, and is a little > awkward from an application point of view. > > What I suggest for the new API instead is the ability to specify one > bit-mask per rule, and let the PMD deal with HW limitations by automatically > configuring global bitmasks from the first added rule, then refusing to add > subsequent rules if they specify a conflicting bit-mask. Existing rules > remain unaffected that way, and applications do not have to be extra > cautious. > [Sugesh] The issue with that approach is, the hardware simply discards the rule when it is a super set of first one eventhough the hardware is capable of handling it. How its guaranteed the first rule will set the bitmask for all the subsequent rules. How about having a CLASSIFER_TYPE for the classifier. Every port can have set of supported flow types(for eg: L3_TYPE, L4_TYPE, L4_TYPE_8BYTE_FLEX, L4_TYPE_16BYTE_FLEX) based on the underlying FDIR support. Application can query this and set the type accordingly while initializing the port. This way the first rule need not set all the bits that may needed in the future rules. > > > ``PASSTHRU`` > > > > > > > > > Leaves packets up for additional processing by subsequent flow rules. > This > > > is the default when a rule does not contain a terminating action, but can > be > > > specified to force a rule to become non-terminating. > > > > > > - No configurable property. > > > > > > +---+ > > > | PASSTHRU | > > > +===+ > > > | no properties | > > > +---+
[dpdk-dev] [PATCH] lib: move rte_ring read barrier to correct location
Hi , > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Juhamatti Kuusisaari > Sent: Monday, July 11, 2016 11:21 AM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH] lib: move rte_ring read barrier to correct > location > > Fix the location of the rte_ring data dependency read barrier. > It needs to be called before accessing indexed data to ensure > that the data itself is guaranteed to be correctly updated. > > See more details at kernel/Documentation/memory-barriers.txt > section 'Data dependency barriers'. Any explanation why? >From my point smp_rmb()s are on the proper places here :) Konstantin > > Signed-off-by: Juhamatti Kuusisaari > --- > lib/librte_ring/rte_ring.h | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/lib/librte_ring/rte_ring.h b/lib/librte_ring/rte_ring.h > index eb45e41..a923e49 100644 > --- a/lib/librte_ring/rte_ring.h > +++ b/lib/librte_ring/rte_ring.h > @@ -662,9 +662,10 @@ __rte_ring_mc_do_dequeue(struct rte_ring *r, void > **obj_table, > cons_next); > } while (unlikely(success == 0)); > > + rte_smp_rmb(); > + > /* copy in table */ > DEQUEUE_PTRS(); > - rte_smp_rmb(); > > /* > * If there are other dequeues in progress that preceded us, > @@ -746,9 +747,10 @@ __rte_ring_sc_do_dequeue(struct rte_ring *r, void > **obj_table, > cons_next = cons_head + n; > r->cons.head = cons_next; > > + rte_smp_rmb(); > + > /* copy in table */ > DEQUEUE_PTRS(); > - rte_smp_rmb(); > > __RING_STAT_ADD(r, deq_success, n); > r->cons.tail = cons_next; > -- > 2.9.0 > > > > The information contained in this message may be privileged > and confidential and protected from disclosure. If the reader > of this message is not the intended recipient, or an employee > or agent responsible for delivering this message to the > intended recipient, you are hereby notified that any reproduction, > dissemination or distribution of this communication is strictly > prohibited. If you have received this communication in error, > please notify us immediately by replying to the message and > deleting it from your computer. Thank you. Coriant-Tellabs >
[dpdk-dev] [PATCH] vhost: fix segfault on bad descriptor address.
On Mon, Jul 11, 2016 at 12:50:24PM +0300, Ilya Maximets wrote:
> On 11.07.2016 11:38, Yuanhan Liu wrote:
> > On Sun, Jul 10, 2016 at 09:17:31PM +0800, Yuanhan Liu wrote:
> >> On Fri, Jul 08, 2016 at 02:48:56PM +0300, Ilya Maximets wrote:
> >>>
> >>> Another point is that crash constantly happens on queue_id=3 (second RX
> >>> queue) in
> >>> my scenario. It is newly allocated virtqueue while reconfiguration from
> >>> rxq=1 to
> >>> rxq=2.
> >>
> >> That's a valuable message: what's your DPDK HEAD commit while triggering
> >> this issue?
>
> fbfd99551ca3 ("mbuf: add raw allocation function")
>
> >
> > I guess I have understood what goes wrong in you case.
> >
> > I would guess that your vhost has 2 queues (here I mean queue-pairs,
> > including one Tx and Rx queue; below usage is the same) configured,
> > so does to your QEMU. However, you just enabled 1 queue while starting
> > testpmd inside the guest, and you want to enable 2 queues by running
> > following testpmd commands:
> >
> > stop
> > port stop all
> > port config all rxq 2
> > port config all txq 2
> > port start all
> >
> > Badly, that won't work for current virtio PMD implementation, and what's
> > worse, it triggers a vhost crash, the one you saw.
> >
> > Here is how it comes. Since you just enabled 1 queue while starting
> > testpmd, it will setup 1 queue only, meaning only one queue's **valid**
> > information will be sent to vhost. You might see SET_VRING_ADDR
> > (and related vhost messages) for the other queue as well, but they
> > are just the dummy messages: they don't include any valid/real
> > information about the 2nd queue: the driver don't setup it after all.
> >
> > So far, so good. It became broken when you run above commands. Those
> > commands do setup for the 2nd queue, however, they failed to trigger
> > the QEMU virtio device to start the vhost-user negotiation, meaning
> > no SET_VRING_ADDR will be sent for the 2nd queue, leaving vhost
> > untold and not updated.
> >
> > What's worse, above commands trigger the QEMU to send SET_VRING_ENABLE
> > messages, to enable all the vrings. And since the vrings for the 2nd
> > queue are not properly configured, the crash happens.
>
> Hmm, why 2nd queue works properly with my fix to vhost in this case?
Hmm, really? You are sure that data flows in your 2nd queue after those
commands? From what I know is that your patch just avoid a crash, but
does not fix it.
> > So maybe we should do virtio reset on port start?
>
> I guess it was removed by this patch:
> a85786dc816f ("virtio: fix states handling during initialization").
Seems yes.
--yliu
[dpdk-dev] [PATCH] lib: move rte_ring read barrier to correct location
Hi, > > -Original Message- > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Juhamatti > > Kuusisaari > > Sent: Monday, July 11, 2016 11:21 AM > > To: dev at dpdk.org > > Subject: [dpdk-dev] [PATCH] lib: move rte_ring read barrier to correct > > location > > > > Fix the location of the rte_ring data dependency read barrier. > > It needs to be called before accessing indexed data to ensure that the > > data itself is guaranteed to be correctly updated. > > > > See more details at kernel/Documentation/memory-barriers.txt > > section 'Data dependency barriers'. > > > Any explanation why? > From my point smp_rmb()s are on the proper places here :) Konstantin The problem here is that on a weak memory model system the CPU is allowed to load the address data out-of-order in advance. If the read barrier is after the DEQUEUE, you might end up having the old data there on a race situation when the buffer is continuously full. Having it before the DEQUEUE guarantees that the load is not done in advance. On Intel, it should not matter due to different memory model, so this is limited to weak memory model systems. -- Juhamatti > > > > Signed-off-by: Juhamatti Kuusisaari > > --- > > lib/librte_ring/rte_ring.h | 6 -- > > 1 file changed, 4 insertions(+), 2 deletions(-) > > > > diff --git a/lib/librte_ring/rte_ring.h b/lib/librte_ring/rte_ring.h > > index eb45e41..a923e49 100644 > > --- a/lib/librte_ring/rte_ring.h > > +++ b/lib/librte_ring/rte_ring.h > > @@ -662,9 +662,10 @@ __rte_ring_mc_do_dequeue(struct rte_ring *r, > void **obj_table, > > cons_next); > > } while (unlikely(success == 0)); > > > > + rte_smp_rmb(); > > + > > /* copy in table */ > > DEQUEUE_PTRS(); > > - rte_smp_rmb(); > > > > /* > > * If there are other dequeues in progress that preceded us, > > @@ -746,9 +747,10 @@ __rte_ring_sc_do_dequeue(struct rte_ring *r, > void **obj_table, > > cons_next = cons_head + n; > > r->cons.head = cons_next; > > > > + rte_smp_rmb(); > > + > > /* copy in table */ > > DEQUEUE_PTRS(); > > - rte_smp_rmb(); > > > > __RING_STAT_ADD(r, deq_success, n); > > r->cons.tail = cons_next; > > -- > > 2.9.0 > > > > > > > == > == > > The information contained in this message may be privileged and > > confidential and protected from disclosure. If the reader of this > > message is not the intended recipient, or an employee or agent > > responsible for delivering this message to the intended recipient, you > > are hereby notified that any reproduction, dissemination or > > distribution of this communication is strictly prohibited. If you have > > received this communication in error, please notify us immediately by > > replying to the message and deleting it from your computer. Thank you. > > Coriant-Tellabs > > > == > ==
[dpdk-dev] [PATCH v2] librte_pmd_bond: fix exported symbol versioning
*update in v2*
- add missing changes in rte_eth_bond_8023ad.h
The older versions of rte_eth_bond_8023ad_conf_get and
rte_eth_bond_8023ad_setup were available in the old way since 2.0 - at
least according to the map file.
But versioning in the code was set to 16.04.
That breaks compatibility checks for 2.0 on that library.
For example with the dpdk abi checker:
http://people.canonical.com/~paelzer/compat_report.html
To fix, version the old symbols on the 2.0 version as they were
initially added to the map file.
See http://people.canonical.com/~paelzer/compat_report.html
Fixes: dc40f17a ("net/bonding: allow external state machine in mode 4")
Signed-off-by: Christian Ehrhardt
---
drivers/net/bonding/rte_eth_bond_8023ad.c | 12 ++--
drivers/net/bonding/rte_eth_bond_8023ad.h | 4 ++--
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/net/bonding/rte_eth_bond_8023ad.c
b/drivers/net/bonding/rte_eth_bond_8023ad.c
index 48a50e4..2f7ae70 100644
--- a/drivers/net/bonding/rte_eth_bond_8023ad.c
+++ b/drivers/net/bonding/rte_eth_bond_8023ad.c
@@ -1068,7 +1068,7 @@ bond_mode_8023ad_conf_assign(struct mode8023ad_private
*mode4,
}
static void
-bond_mode_8023ad_setup_v1604(struct rte_eth_dev *dev,
+bond_mode_8023ad_setup_v20(struct rte_eth_dev *dev,
struct rte_eth_bond_8023ad_conf *conf)
{
struct rte_eth_bond_8023ad_conf def_conf;
@@ -1214,7 +1214,7 @@ free_out:
}
int
-rte_eth_bond_8023ad_conf_get_v1604(uint8_t port_id,
+rte_eth_bond_8023ad_conf_get_v20(uint8_t port_id,
struct rte_eth_bond_8023ad_conf *conf)
{
struct rte_eth_dev *bond_dev;
@@ -1229,7 +1229,7 @@ rte_eth_bond_8023ad_conf_get_v1604(uint8_t port_id,
bond_mode_8023ad_conf_get(bond_dev, conf);
return 0;
}
-VERSION_SYMBOL(rte_eth_bond_8023ad_conf_get, _v1604, 16.04);
+VERSION_SYMBOL(rte_eth_bond_8023ad_conf_get, _v20, 2.0);
int
rte_eth_bond_8023ad_conf_get_v1607(uint8_t port_id,
@@ -1278,7 +1278,7 @@ bond_8023ad_setup_validate(uint8_t port_id,
}
int
-rte_eth_bond_8023ad_setup_v1604(uint8_t port_id,
+rte_eth_bond_8023ad_setup_v20(uint8_t port_id,
struct rte_eth_bond_8023ad_conf *conf)
{
struct rte_eth_dev *bond_dev;
@@ -1289,11 +1289,11 @@ rte_eth_bond_8023ad_setup_v1604(uint8_t port_id,
return err;
bond_dev = &rte_eth_devices[port_id];
- bond_mode_8023ad_setup_v1604(bond_dev, conf);
+ bond_mode_8023ad_setup_v20(bond_dev, conf);
return 0;
}
-VERSION_SYMBOL(rte_eth_bond_8023ad_setup, _v1604, 16.04);
+VERSION_SYMBOL(rte_eth_bond_8023ad_setup, _v20, 2.0);
int
rte_eth_bond_8023ad_setup_v1607(uint8_t port_id,
diff --git a/drivers/net/bonding/rte_eth_bond_8023ad.h
b/drivers/net/bonding/rte_eth_bond_8023ad.h
index 1de34bc..6b8ff57 100644
--- a/drivers/net/bonding/rte_eth_bond_8023ad.h
+++ b/drivers/net/bonding/rte_eth_bond_8023ad.h
@@ -188,7 +188,7 @@ int
rte_eth_bond_8023ad_conf_get(uint8_t port_id,
struct rte_eth_bond_8023ad_conf *conf);
int
-rte_eth_bond_8023ad_conf_get_v1604(uint8_t port_id,
+rte_eth_bond_8023ad_conf_get_v20(uint8_t port_id,
struct rte_eth_bond_8023ad_conf *conf);
int
rte_eth_bond_8023ad_conf_get_v1607(uint8_t port_id,
@@ -209,7 +209,7 @@ int
rte_eth_bond_8023ad_setup(uint8_t port_id,
struct rte_eth_bond_8023ad_conf *conf);
int
-rte_eth_bond_8023ad_setup_v1604(uint8_t port_id,
+rte_eth_bond_8023ad_setup_v20(uint8_t port_id,
struct rte_eth_bond_8023ad_conf *conf);
int
rte_eth_bond_8023ad_setup_v1607(uint8_t port_id,
--
2.7.4
[dpdk-dev] [PATCH v3 01/13] e1000: move pci device ids to driver
Hello all, On Mon, Jul 11, 2016 at 7:56 AM, Thomas Monjalon wrote: > 2016-07-11 13:33, Yuanhan Liu: >> I'm not quite sure I understood it well: are you asking us to resend >> what David has already send, say me for resending the virtio part? >> >> If so, what's the point of that? What's worse, it's likely to fail >> apply (due to conflicts), as every one of us make a patch based on >> the same base while touching some same files. > > Good point. > There were some changes since the patches from David (and a new bnxt). > That's why I was thinking to ask maintainers to take care of this change. > But maybe it's better to do the change in one patchset. > David, ok to refresh these patches? Now that we have a modinfo-like infra and the test code is exempt from igb pci ids, all that remains (to fully get rid of this header) are bypass api and kni/ethtool. So the deal with Thomas is that I refresh those patches letting igb and ixgbe pmd as is. Will send this later. -- David Marchand
[dpdk-dev] [PATCH] lib: move rte_ring read barrier to correct location
Hi, On 07/11/2016 01:22 PM, Kuusisaari, Juhamatti wrote: > > Hi, > >>> -Original Message- >>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Juhamatti >>> Kuusisaari >>> Sent: Monday, July 11, 2016 11:21 AM >>> To: dev at dpdk.org >>> Subject: [dpdk-dev] [PATCH] lib: move rte_ring read barrier to correct >>> location >>> >>> Fix the location of the rte_ring data dependency read barrier. >>> It needs to be called before accessing indexed data to ensure that the >>> data itself is guaranteed to be correctly updated. >>> >>> See more details at kernel/Documentation/memory-barriers.txt >>> section 'Data dependency barriers'. >> >> >> Any explanation why? >> From my point smp_rmb()s are on the proper places here :) Konstantin > > The problem here is that on a weak memory model system the CPU is > allowed to load the address data out-of-order in advance. > If the read barrier is after the DEQUEUE, you might end up having the old > data there on a race situation when the buffer is continuously full. > Having it before the DEQUEUE guarantees that the load is not done > in advance. > > On Intel, it should not matter due to different memory model, so this is > limited to weak memory model systems. I agree with Juhamatti. To me, the reading of consumer_head must occur before the reading of objects ptrs. That was the case before, and this is something I already noticed when I sent that mail: http://dpdk.org/ml/archives/dev/2014-March/001742.html At that time, only Intel CPUs were supported, so it did not make any difference. Juhamatti, do you have a setup where you can trigger the issue or is it something you've seen by code review? Thanks, Olivier
[dpdk-dev] [PATCH] vhost: fix segfault on bad descriptor address.
On 11.07.2016 14:05, Yuanhan Liu wrote:
> On Mon, Jul 11, 2016 at 12:50:24PM +0300, Ilya Maximets wrote:
>> On 11.07.2016 11:38, Yuanhan Liu wrote:
>>> On Sun, Jul 10, 2016 at 09:17:31PM +0800, Yuanhan Liu wrote:
On Fri, Jul 08, 2016 at 02:48:56PM +0300, Ilya Maximets wrote:
>
> Another point is that crash constantly happens on queue_id=3 (second RX
> queue) in
> my scenario. It is newly allocated virtqueue while reconfiguration from
> rxq=1 to
> rxq=2.
That's a valuable message: what's your DPDK HEAD commit while triggering
this issue?
>>
>> fbfd99551ca3 ("mbuf: add raw allocation function")
>>
>>>
>>> I guess I have understood what goes wrong in you case.
>>>
>>> I would guess that your vhost has 2 queues (here I mean queue-pairs,
>>> including one Tx and Rx queue; below usage is the same) configured,
>>> so does to your QEMU. However, you just enabled 1 queue while starting
>>> testpmd inside the guest, and you want to enable 2 queues by running
>>> following testpmd commands:
>>>
>>> stop
>>> port stop all
>>> port config all rxq 2
>>> port config all txq 2
>>> port start all
>>>
>>> Badly, that won't work for current virtio PMD implementation, and what's
>>> worse, it triggers a vhost crash, the one you saw.
>>>
>>> Here is how it comes. Since you just enabled 1 queue while starting
>>> testpmd, it will setup 1 queue only, meaning only one queue's **valid**
>>> information will be sent to vhost. You might see SET_VRING_ADDR
>>> (and related vhost messages) for the other queue as well, but they
>>> are just the dummy messages: they don't include any valid/real
>>> information about the 2nd queue: the driver don't setup it after all.
>>>
>>> So far, so good. It became broken when you run above commands. Those
>>> commands do setup for the 2nd queue, however, they failed to trigger
>>> the QEMU virtio device to start the vhost-user negotiation, meaning
>>> no SET_VRING_ADDR will be sent for the 2nd queue, leaving vhost
>>> untold and not updated.
>>>
>>> What's worse, above commands trigger the QEMU to send SET_VRING_ENABLE
>>> messages, to enable all the vrings. And since the vrings for the 2nd
>>> queue are not properly configured, the crash happens.
>>
>> Hmm, why 2nd queue works properly with my fix to vhost in this case?
>
> Hmm, really? You are sure that data flows in your 2nd queue after those
> commands? From what I know is that your patch just avoid a crash, but
> does not fix it.
Oh, sorry. Yes, it doesn't work. With my patch applied I have a QEMU hang.
>>> So maybe we should do virtio reset on port start?
>>
>> I guess it was removed by this patch:
>> a85786dc816f ("virtio: fix states handling during initialization").
>
> Seems yes.
>
> --yliu
>
>
[dpdk-dev] [PATCH v6 0/4] support reset of VF link
On Mon, 2016-07-11 at 01:32 +, Lu, Wenzhuo wrote: > > > > Unfortunately I found one issue: if PF is down, and then the VF on the > > guest is > > down as well (ip link down) and then goes back up before the PF, then > > calling > > rte_eth_dev_reset will return 0 (success), even though the PF is still down > > and it > > should fail. This is with ixgbe. Any idea what could be the problem? > I've found this interesting thing. I believe it?s the HW difference between > igb and ixgbe. When the link is down, ixgbe VF can be reset successfully but > igb VF cannot. The expression is the registers of the ixgbe VF can be > accessed when the PF link is down but igb VF cannot. > It means, on ixgbe, when PF link is down, we reset the VF link. Then PF link > is up, we receive the message again and reset the VF link again. What message do you refer to here? I am seeing the RESET callback only when the PF goes down, not when it goes up. At the moment, with ixgbe, this happens: PF down -> reset notification, rte_eth_dev_reset keeps failing -> VF down -> VF up -> rte_eth_dev_reset in a loop/timer succeeds -> PF up -> VF link has no-carrier, and traffic does NOT go through The problem is that there is just no way of being notified that PF is up, and if rte_eth_dev_reset succeeds I have no way of knowing that I need to run it again. > But on igb, when PF link is down, we cannot reset VF link successfully, so > when the PF link is up, we cannot receive the message. No trigger for us to > reset the VF link again. That's why on igb we have to try again and again > until it succeed, means until PF link is up. > So the return 0 by rte_eth_dev_reset means the resetting succeeded, not mean > the rx/tx is ready. Rx/tx has to depend on the PF link is up. -- Kind regards, Luca Boccassi
[dpdk-dev] [PATCH v3 01/13] e1000: move pci device ids to driver
On Mon, Jul 11, 2016 at 01:35:46PM +0200, David Marchand wrote: > Hello all, > > On Mon, Jul 11, 2016 at 7:56 AM, Thomas Monjalon > wrote: > > 2016-07-11 13:33, Yuanhan Liu: > >> I'm not quite sure I understood it well: are you asking us to resend > >> what David has already send, say me for resending the virtio part? > >> > >> If so, what's the point of that? What's worse, it's likely to fail > >> apply (due to conflicts), as every one of us make a patch based on > >> the same base while touching some same files. > > > > Good point. > > There were some changes since the patches from David (and a new bnxt). > > That's why I was thinking to ask maintainers to take care of this change. > > But maybe it's better to do the change in one patchset. > > David, ok to refresh these patches? > > Now that we have a modinfo-like infra and the test code is exempt from > igb pci ids, all that remains (to fully get rid of this header) are > bypass api and kni/ethtool. > So the deal with Thomas is that I refresh those patches letting igb > and ixgbe pmd as is. > > Will send this later. Thanks, and feel free to put my ack for the virtio part. Acked-by: Yuanhan Liu Great work, BTW! --yliu
[dpdk-dev] [PATCH] lib: move rte_ring read barrier to correct location
> Hi, > > > > -Original Message- > > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Juhamatti > > > Kuusisaari > > > Sent: Monday, July 11, 2016 11:21 AM > > > To: dev at dpdk.org > > > Subject: [dpdk-dev] [PATCH] lib: move rte_ring read barrier to correct > > > location > > > > > > Fix the location of the rte_ring data dependency read barrier. > > > It needs to be called before accessing indexed data to ensure that the > > > data itself is guaranteed to be correctly updated. > > > > > > See more details at kernel/Documentation/memory-barriers.txt > > > section 'Data dependency barriers'. > > > > > > Any explanation why? > > From my point smp_rmb()s are on the proper places here :) Konstantin > > The problem here is that on a weak memory model system the CPU is > allowed to load the address data out-of-order in advance. > If the read barrier is after the DEQUEUE, you might end up having the old > data there on a race situation when the buffer is continuously full. > Having it before the DEQUEUE guarantees that the load is not done > in advance. Sorry, still didn't see any race condition in the current code. Can you provide any particular example? >From other side, moving smp_rmb() before dequeueing the objects, could introduce a race condition, on cpus where later writes can be reordered with earlier reads. Konstantin > > On Intel, it should not matter due to different memory model, so this is > limited to weak memory model systems. > > -- > Juhamatti > > > > > > > Signed-off-by: Juhamatti Kuusisaari > > > --- > > > lib/librte_ring/rte_ring.h | 6 -- > > > 1 file changed, 4 insertions(+), 2 deletions(-) > > > > > > diff --git a/lib/librte_ring/rte_ring.h b/lib/librte_ring/rte_ring.h > > > index eb45e41..a923e49 100644 > > > --- a/lib/librte_ring/rte_ring.h > > > +++ b/lib/librte_ring/rte_ring.h > > > @@ -662,9 +662,10 @@ __rte_ring_mc_do_dequeue(struct rte_ring *r, > > void **obj_table, > > > cons_next); > > > } while (unlikely(success == 0)); > > > > > > + rte_smp_rmb(); > > > + > > > /* copy in table */ > > > DEQUEUE_PTRS(); > > > - rte_smp_rmb(); > > > > > > /* > > > * If there are other dequeues in progress that preceded us, > > > @@ -746,9 +747,10 @@ __rte_ring_sc_do_dequeue(struct rte_ring *r, > > void **obj_table, > > > cons_next = cons_head + n; > > > r->cons.head = cons_next; > > > > > > + rte_smp_rmb(); > > > + > > > /* copy in table */ > > > DEQUEUE_PTRS(); > > > - rte_smp_rmb(); > > > > > > __RING_STAT_ADD(r, deq_success, n); > > > r->cons.tail = cons_next; > > > -- > > > 2.9.0 > > > > > > > > > > > == > > == > > > The information contained in this message may be privileged and > > > confidential and protected from disclosure. If the reader of this > > > message is not the intended recipient, or an employee or agent > > > responsible for delivering this message to the intended recipient, you > > > are hereby notified that any reproduction, dissemination or > > > distribution of this communication is strictly prohibited. If you have > > > received this communication in error, please notify us immediately by > > > replying to the message and deleting it from your computer. Thank you. > > > Coriant-Tellabs > > > > > == > > ==
[dpdk-dev] [PATCH v4] mk: filter duplicate configuration entries
2016-07-06 11:13, Christian Ehrhardt: > *updates in v4* > - replace awk usage with sed > - re-add the old loop to be able to get rid of awk > - add more explanation to the header of the makefile section > > *updates in v3* > - replace tac with sed '1!G;h;$!d' to avoid build time dependency > > *updates in v2* > - move to .config target > - fix usage order of tac > - simplify inner section by only using awk (instead of awk+loop+bash+sed) > > Due to the hierarchy and the demand to keep the base config showing all > options, some config keys end up multiple times in the .config file. > > Due to the way the actual config is sourced only the last entry is > important. That can confuse people changing values in .config which > are then ignored. > > A suggested solution was to filter for duplicates at the end of the > actual config step which is implemented here. > > Signed-off-by: Christian Ehrhardt Applied, thanks
[dpdk-dev] [PATCH v2] librte_pmd_bond: fix exported symbol versioning
2016-07-11 13:27, Christian Ehrhardt:
> *update in v2*
> - add missing changes in rte_eth_bond_8023ad.h
>
> The older versions of rte_eth_bond_8023ad_conf_get and
> rte_eth_bond_8023ad_setup were available in the old way since 2.0 - at
> least according to the map file.
>
> But versioning in the code was set to 16.04.
> That breaks compatibility checks for 2.0 on that library.
>
> For example with the dpdk abi checker:
> http://people.canonical.com/~paelzer/compat_report.html
>
> To fix, version the old symbols on the 2.0 version as they were
> initially added to the map file.
>
> See http://people.canonical.com/~paelzer/compat_report.html
>
> Fixes: dc40f17a ("net/bonding: allow external state machine in mode 4")
>
> Signed-off-by: Christian Ehrhardt
Applied, thanks
[dpdk-dev] [PATCH v1 00/15] rte_driver/device infrastructure
Hi Jan, On Saturday 09 July 2016 12:39 AM, Jan Viktorin wrote: > Hello, > > based on the discussions with Shreyansh, I propose a patchset with > the important EAL changes. It is incomplete and I suppose to extend > and change certain things in the foreseeable future. > > Important notes: > > * pmd_type is removed > * introduced rte_vdev_driver inheriting rte_driver > * PMD_REGISTER_DRIVER is replaced by RTE_EAL_VDRV_REGISTER > * rte_driver/device integrated into rte_pci_driver/device > * all drivers and devices are in 2 lists - general and bus-specific > > Shreyansh, I hope I do not duplicate your work. I tried to avoid touching > pmd_type but it quite complicated... There is also an initial generalization > of rte_pci_resource. More such generalizations are to be done. My mistake - I didn't even notice this email somehow. In fact, I noticed right when I was about to send the v6 - while searching for my old conversation. I will look through these patches and remove any conflicting change (as much as possible) - I don't think it there would much conflicts except the VDEV area. And, cursory look shows not much duplication - don't worry. > > The init/uninit functions cannot be generalized easily, I think. Both PCI > and VDEV have different requirements. > > No idea about hotplug... > > > The patchset is based on (all rebased on top of 34d279): > > [PATCH v5 00/17] Prepare for rte_device / rte_driver > > > Thanks anybody for some quick review and notes. Added to my list of todo. I will review and reply soon. > > Regards > Jan - Shreyansh [...]
[dpdk-dev] [PATCH v2] app/testpmd: bypass code cleanup
2016-07-11 16:29, Wenzhuo Lu: > In testpmd code, device id is used directly to check if bypass > is supported. But APP should not know the details of HW, the NIC > specific info should not be exposed here. > As every bypass API does know if it's supported, no need to check > that at first. So, this patch removes the *bypass_is_supported*. > > Suggested-by: Jingjing Wu > Signed-off-by: Wenzhuo Lu Applied, thanks
[dpdk-dev] [PATCH v1 01/15] eal: extract vdev infra
Hi Jan,
Some comments.
On Saturday 09 July 2016 12:39 AM, Jan Viktorin wrote:
> Move all PMD_VDEV-specific code into a separate module and header
> file to not polute the generic code anymore. There is now a list
> of virtual devices available.
>
> The rte_vdev_driver integrates the original rte_driver inside
> (C inheritance). The rte_driver will be however change in the
> future to serve as a common base for all other types of drivers.
>
> The existing PMDs (PMD_VDEV) are to be modified later (there is
> no change for them at the moment).
>
> There is however a inconsistency. The functions rte_eal_vdev_init
> and rte_eal_vdev_uninit are still placed in the rte_dev.h (instead
> of the rte_vdev.h).
>
> Signed-off-by: Jan Viktorin
> ---
> lib/librte_eal/bsdapp/eal/Makefile | 1 +
> lib/librte_eal/common/Makefile | 2 +-
> lib/librte_eal/common/eal_common_dev.c | 54 +---
> lib/librte_eal/common/eal_common_vdev.c | 104
> +++
> lib/librte_eal/common/include/rte_dev.h | 1 +
> lib/librte_eal/common/include/rte_vdev.h | 83
> lib/librte_eal/linuxapp/eal/Makefile | 1 +
> 7 files changed, 192 insertions(+), 54 deletions(-)
> create mode 100644 lib/librte_eal/common/eal_common_vdev.c
> create mode 100644 lib/librte_eal/common/include/rte_vdev.h
>
> diff --git a/lib/librte_eal/bsdapp/eal/Makefile
> b/lib/librte_eal/bsdapp/eal/Makefile
> index 698fa0a..b7e94a4 100644
> --- a/lib/librte_eal/bsdapp/eal/Makefile
> +++ b/lib/librte_eal/bsdapp/eal/Makefile
[...]
> diff --git a/lib/librte_eal/common/eal_common_vdev.c
> b/lib/librte_eal/common/eal_common_vdev.c
> new file mode 100644
> index 000..ea83c41
> --- /dev/null
> +++ b/lib/librte_eal/common/eal_common_vdev.c
> @@ -0,0 +1,104 @@
> +/*-
> + * BSD LICENSE
> + *
> + * Copyright(c) 2016 RehiveTech. All rights reserved.
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions
> + * are met:
> + *
> + * * Redistributions of source code must retain the above copyright
> + * notice, this list of conditions and the following disclaimer.
> + * * Redistributions in binary form must reproduce the above copyright
> + * notice, this list of conditions and the following disclaimer in
> + * the documentation and/or other materials provided with the
> + * distribution.
> + * * Neither the name of RehiveTech nor the names of its
> + * contributors may be used to endorse or promote products derived
> + * from this software without specific prior written permission.
> + *
> + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
> + * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
> + * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
> + * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
> + * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
> + * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
> + * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
> + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
> + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
> + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
> + * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> + */
> +
> +#include
> +#include
> +#include
> +
> +struct vdev_driver_list vdev_driver_list =
> + TAILQ_HEAD_INITIALIZER(vdev_driver_list);
> +
> +/* register a driver */
> +void
> +rte_eal_vdrv_register(struct rte_vdev_driver *driver)
> +{
> + TAILQ_INSERT_TAIL(&vdev_driver_list, driver, next);
> +}
> +
> +/* unregister a driver */
> +void
> +rte_eal_vdrv_unregister(struct rte_vdev_driver *driver)
> +{
> + TAILQ_REMOVE(&vdev_driver_list, driver, next);
> +}
> +
> +int
> +rte_eal_vdev_init(const char *name, const char *args)
> +{
> + struct rte_vdev_driver *driver;
> +
> + if (name == NULL)
> + return -EINVAL;
> +
> + TAILQ_FOREACH(driver, &vdev_driver_list, next) {
> + if (driver->driver.type != PMD_VDEV)
> + continue;
Now that two separate lists for vdev and pdev exist, we don't need this check
anymore.
In fact, PMD_VDEV might not even exist.
> +
> + /*
> + * search a driver prefix in virtual device name.
> + * For example, if the driver is pcap PMD, driver->name
> + * will be "eth_pcap", but "name" will be "eth_pcapN".
> + * So use strncmp to compare.
> + */
> + if (!strncmp(driver->driver.name, name,
> strlen(driver->driver.name)))
> + return driver->driver.init(name, args);
> + }
> +
> + RTE_LOG(ERR, EAL, "no driver found for
[dpdk-dev] [PATCH] app/testpmd: add timer based fwd Rx queue flushing
> > Testpmd can stuck inside do while loop of the flush_fwd_rx_queues()
> > function. As non-zero packets are returned always by rte_eth_rx_burst()
> > function when compiled with no optimizations and if input line rate is
> > high. "do while" loop must exit at one stage to proceed further to
> > enable packet forwarding and forward the packets. So timer is set to
> > exit the do while loop after 1 second.
> >
> > Fixes: af75078f ("first public release")
> >
> > Signed-off-by: Reshma Pattan
>
> Acked-by: Pablo de Lara
Applied, thanks
[dpdk-dev] QoS config variables
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of sreenaath > vasudevan > Sent: Saturday, July 9, 2016 12:23 AM > To: dev at dpdk.org > Subject: [dpdk-dev] QoS config variables > > Hi > Can someone throw some light on the following DPDK QoS config variables? > > A) In struct *rte_sched_subport_params* AND *rte_sched_pipe_params* >1) tb_rate - Is the provisioned rate at which the TB can be filled while > enqueuing OR the TB rate slice allotted to this subport ? >2) tb_size >3) tc_rate - Is tc_period the time slice given to each class within a > subport? >4) tc_period - Does tc_rate represent the bw rate provisioning for that > class? > > It would be nice if someone could throw the relationship between the above > parameters and the QoS scheduling algorithm > > Thanks ! > > -- > regards > sreenaath Hi Sreenaath, Please check out the QoS documentation: http://www.dpdk.org/doc/guides/prog_guide/qos_framework.html. There is a section on traffic shaping and a section on traffic classes where there parameters are explained in detail. These parameters are also explained by the comments in file "rte_sched.h". Also this Youtube video might be useful to you: https://youtu.be/_PPklkWGugs TB stands for Token Bucket, TC stands for Traffic Class. The rate parameters are specified in bytes per second. The traffic classes share the subport/pipe bandwidth and are scheduled in strict priority. Regards, Cristian
[dpdk-dev] [PATCH] app/testpmd: refactor of RSS fwd config
2016-07-05 10:20, Ilya Maximets:
> Since
> commit f2bb7ae1d204 ("app/testpmd: handle all Rx queues in RSS setup")
> behavior of rss_fwd_config_setup() changed and description of this
> function is wrong now.
>
> Also, there is a type mismatch in a loop.
>
> Signed-off-by: Ilya Maximets
Applied, thanks
[dpdk-dev] [PATCH v1 01/15] eal: extract vdev infra
On Mon, 11 Jul 2016 18:59:48 +0530
Shreyansh jain wrote:
> Hi Jan,
>
> Some comments.
>
> On Saturday 09 July 2016 12:39 AM, Jan Viktorin wrote:
> > Move all PMD_VDEV-specific code into a separate module and header
> > file to not polute the generic code anymore. There is now a list
> > of virtual devices available.
> >
> > The rte_vdev_driver integrates the original rte_driver inside
> > (C inheritance). The rte_driver will be however change in the
> > future to serve as a common base for all other types of drivers.
> >
> > The existing PMDs (PMD_VDEV) are to be modified later (there is
> > no change for them at the moment).
> >
> > There is however a inconsistency. The functions rte_eal_vdev_init
> > and rte_eal_vdev_uninit are still placed in the rte_dev.h (instead
> > of the rte_vdev.h).
> >
> > Signed-off-by: Jan Viktorin
> > ---
[...]
> > +
> > +/* unregister a driver */
> > +void
> > +rte_eal_vdrv_unregister(struct rte_vdev_driver *driver)
> > +{
> > + TAILQ_REMOVE(&vdev_driver_list, driver, next);
> > +}
> > +
> > +int
> > +rte_eal_vdev_init(const char *name, const char *args)
> > +{
> > + struct rte_vdev_driver *driver;
> > +
> > + if (name == NULL)
> > + return -EINVAL;
> > +
> > + TAILQ_FOREACH(driver, &vdev_driver_list, next) {
> > + if (driver->driver.type != PMD_VDEV)
> > + continue;
>
> Now that two separate lists for vdev and pdev exist, we don't need this check
> anymore.
> In fact, PMD_VDEV might not even exist.
Solved already in the next 2 patches.
>
> > +
> > + /*
> > +* search a driver prefix in virtual device name.
> > +* For example, if the driver is pcap PMD, driver->name
> > +* will be "eth_pcap", but "name" will be "eth_pcapN".
> > +* So use strncmp to compare.
> > +*/
> > + if (!strncmp(driver->driver.name, name,
> > strlen(driver->driver.name)))
> > + return driver->driver.init(name, args);
> > + }
> > +
> > + RTE_LOG(ERR, EAL, "no driver found for %s\n", name);
> > + return -EINVAL;
> > +}
> > +
> > +int
> > +rte_eal_vdev_uninit(const char *name)
> > +{
> > + struct rte_vdev_driver *driver;
> > +
> > + if (name == NULL)
> > + return -EINVAL;
> > +
> > + TAILQ_FOREACH(driver, &vdev_driver_list, next) {
> > + if (driver->driver.type != PMD_VDEV)
> > + continue;
>
> Same as above, redundant check.
Solved already in the next 2 patches.
>
> > +
> > + /*
> > +* search a driver prefix in virtual device name.
> > +* For example, if the driver is pcap PMD, driver->name
> > +* will be "eth_pcap", but "name" will be "eth_pcapN".
> > +* So use strncmp to compare.
> > +*/
> > + if (!strncmp(driver->driver.name, name,
> > strlen(driver->driver.name)))
> > + return driver->driver.uninit(name);
> > + }
> > +
> > + RTE_LOG(ERR, EAL, "no driver found for %s\n", name);
> > + return -EINVAL;
> > +}
> > diff --git a/lib/librte_eal/common/include/rte_dev.h
> > b/lib/librte_eal/common/include/rte_dev.h
> > index b1c0520..2aeb752 100644
> > --- a/lib/librte_eal/common/include/rte_dev.h
> > +++ b/lib/librte_eal/common/include/rte_dev.h
> > @@ -210,6 +210,7 @@ static void devinitfn_ ##d(void)\
> > rte_eal_driver_register(&d);\
> > }
> >
> > +
>
> Probably a stray newline.
Will fix.
>
> > #ifdef __cplusplus
> > }
> > #endif
> > diff --git a/lib/librte_eal/common/include/rte_vdev.h
> > b/lib/librte_eal/common/include/rte_vdev.h
> > new file mode 100644
> > index 000..523bd92
> > --- /dev/null
> > +++ b/lib/librte_eal/common/include/rte_vdev.h
> > @@ -0,0 +1,83 @@
[...]
> > +/**
> > + * Unregister a virtual device driver.
> > + *
> > + * @param driver
> > + * A pointer to a rte_vdev_driver structure describing the driver
> > + * to be unregistered.
> > + */
> > +void rte_eal_vdrv_unregister(struct rte_vdev_driver *driver);
> > +
> > +#define RTE_EAL_VDRV_REGISTER(d)\
>
> In the recent commits, I noticed that macros have taken the (name, driver)
> format.
> PMD_REGISTER_DRIVER() (now redundant), DRIVER_REGISTER_PCI_TABLE() ... etc
> It might be better to stick to the same format.
Yes, I will change this when rebasing.
Thanks
Jan
>
> > +RTE_INIT(vdrvinitfn_ ##d);\
> > +static void vdrvinitfn_ ##d(void)\
> > +{\
> > + rte_eal_vdrv_register(&d);\
> > +}
> > +
> > +#ifdef __cplusplus
> > +}
> > +#endif
> > +
> > +#endif
> > diff --git a/lib/librte_eal/linuxapp/eal/Makefile
> > b/lib/librte_eal/linuxapp/eal/Makefile
> > index 30b30f3..9553e97 100644
> > --- a/lib/librte_eal/linuxapp/eal/Makefile
> > +++ b/lib/librte_eal/linuxapp/eal/Makefile
> > @@ -85,6 +85,7 @@ SRCS-$(CONFIG_RTE_EXEC_ENV_LINUXAPP) += eal_common_timer.c
> > SRCS-$(CONFIG_RTE_EXEC_ENV_LINUXAPP) += eal_common_memzone.c
> > SRCS-$(CONFIG_RTE_EXEC_ENV_LINUXAPP) += eal_common_log.c
> > SRCS
[dpdk-dev] [PATCH v2] app/test: fix hexdump length of cipher/plaintexts
2016-07-10 17:16, Deepak Kumar Jain:
> From: Pablo de Lara
>
> Plaintexts and ciphertexts are dumped when debugging is enabled,
> using TEST_HEXDUMP. For Snow3G and KASUMI, their lengths are in bits,
> but TEST_HEXDUMP uses bytes, so lenghts are passed in bytes now.
>
> Fixes: 47df73a1a62f ("app/test: use hexdump if debug log is enabled")
>
> Signed-off-by: Pablo de Lara
> Signed-off-by: Deepak Kumar Jain
Applied, thanks
[dpdk-dev] Redirect all packets to a specific VM pool
Hello,
To be more specific, what I am trying to do it to setup an environment
where I have a physical NIC that has some Virtual Functions configured,
then all the incoming traffic to the NIC should be forwarded to a specific
Virtual Function.
I was able to modify the "VMDQ and DCB Forwarding Sample Application" in
order to forward all the traffic that does not match the filters to a
specific rx queue, unfortunately when I try it with SR-IOV all the traffic
goes the the physical function.
My big question is:
Is it possible to forward all the traffic to a specific Virtual Function?
At least, is it supported by any NIC?
Thank you very much for your help.
PD: I CC'ed the ixgbe and i40e maintainers because those are the drivers
that I am using.
On Mon, Jul 4, 2016 at 11:03 AM, Mauricio V?squez <
mauricio.vasquezbernal at studenti.polito.it> wrote:
> Hello,
>
> I have a setup with SR-IOV where I want to forward all the packets to a
> specific VM pool. I found that in some Intel NICs it is possible to set a
> field called default pool. (Flag DEF_PL within the PFVTCTL register). In
> order to setup this using DPDK, I used the default_pool field in the
> rte_eth_vmdq_rx_conf structure, something like this:
>
> .vmdq_rx_conf =
> {
> .nb_queue_pools = ETH_8_POOLS,
> .enable_default_pool = 1,
> .default_pool = 5,
> .nb_pool_maps = 1,
> .pool_map = {{0, 0},},
> },
>
> However it appears not to be working, all the packets are being forwarded
> to the host pool.
>
> Am I missing something?
> Is there a better approach to reach my goal?
>
> Thank you very much for your help.
>
> Mauricio V.
>
[dpdk-dev] [PATCH v1 1/1] examples/l2fwd-crypto: improve random key generator
2016-06-08 07:46, Azarewicz, PiotrX T: > > 2016-05-25 15:34, Piotr Azarewicz: > > > This patch improve generate_random_key() function by replacing rand() > > > function with reading from /dev/urandom. > > > > > > CID 120136 : Calling risky function (DC.WEAK_CRYPTO) > > > dont_call: rand should not be used for security related applications, > > > as linear congruential algorithms are too easy to break > > > > > > Coverity issue: 120136 > > > > > > Signed-off-by: Piotr Azarewicz > > > > Is it relevant for this example? > > Maybe not. But it don't break anything, and in the end make Coverity tool > happy. > > Declan, please share your opinion. Declan?
[dpdk-dev] [PATCH v1 1/1] examples/bond: fix unchecked return value
2016-06-30 10:13, Declan Doherty:
> On 29/06/16 10:23, ptazarex at ecsmtp.igk.intel.com wrote:
> > The example is calling rte_eal_wait_lcore without checking return value.
> > Now it is fixed by checking the value and print proper message.
> >
> > Coverity issue: 37789
> > Coverity issue: 37790
> > Fixes: cc7e8ae84faa ("examples/bond: add example application for link
> > bonding mode 6")
> >
> > Signed-off-by: Piotr Azarewicz
>
> Acked-by: Declan Doherty
Applied with title "examples/bond: check thread termination", thanks
[dpdk-dev] [PATCH] examples/tep_term: fix out-of-bounds access
2016-07-05 14:15, Beilei Xing:
> Coverity reported lots of out-of-bounds in function
> vxlan_link, these issues should happen when index
> port_id evaluates to 2, cause size of arrays is
> 2 in structure.
> Fix this issue by modifying judgement condition, make
> sure port_id is less than 2.
>
> Coverity issue: 107121, 107122, 107123, 107124, 107125
>
> Fixes: 4abe471ed6fc ("examples/tep_term: implement VXLAN processing")
>
> Signed-off-by: Beilei Xing
Applied, thanks
[dpdk-dev] [PATCH v2] examples/l3fwd: update usage and documentation
> > Update l3fwd example usage and documentation with missing options. > > > > Signed-off-by: Beilei Xing > > Acked-by: John McNamara Applied, thanks
[dpdk-dev] [PATCH v4 00/10] kill global pci device id list (almost)
With the introduction of pmdinfo by Neil, we have almost everything in place
to get rid of the pci devices in eal.
We still have some ties with some pmds for functionalities like kni/ethtool or
ixgbe bypass api, so the plan has switched to touch all pmds but those igb and
ixgbe drivers.
Since we still need rte_pci_dev_ids.h for those drivers, I just stripped the
doxygen parts to stop referencing it in the documentation.
I have validated this patchset by comparing the pmdinfo outputs and just
noticed a difference for enic (where the pci ids were registered twice
before).
Yet, please maintainers review carefully.
Thanks.
Changes since v3:
- dropped my approach at extracting informations from binaries
- let igb{,vf} and ixgbe{,vf} untouched
- rebased on HEAD
- added bnxt
Changes since v2:
- rebased on HEAD
- ena driver has been aligned
- this patchset now depends on [1] as it avoids touching all drivers this way
- not storing the pci ids in a dedicated section anymore, pci drivers are
exported and parsed by a quickly written (and naive) tool
Changes since v1:
- indent fixes in i40e, fm10k, virtio, vmxnet3, enic, bnx2x.
- rebased on head (ixgbe update)
- removed doc update (will be sent separately)
[1]: http://dpdk.org/ml/archives/dev/2016-April/037686.html
--
David Marchand
David Marchand (10):
eal: remove PCI device ids header from doxygen
net/e1000: move em PCI device ids to the driver
net/i40e: move PCI device ids to the driver
net/fm10k: move PCI device ids to the driver
net/virtio: move PCI device ids to the driver
net/vmxnet3: move PCI device ids to the driver
net/enic: move PCI device ids to the driver
net/bnx2x: move PCI device ids to the driver
net/bnxt: move PCI device ids to the driver
net/ena: remove unneeded pci macro
doc/api/doxy-api-index.md | 1 -
drivers/net/bnx2x/bnx2x.c | 3 +-
drivers/net/bnx2x/bnx2x_ethdev.c| 21 +-
drivers/net/bnxt/bnxt_ethdev.c | 27 +-
drivers/net/e1000/e1000_ethdev.h| 2 +
drivers/net/e1000/em_ethdev.c | 37 ++-
drivers/net/ena/ena_ethdev.c| 7 +-
drivers/net/enic/enic_ethdev.c | 12 +-
drivers/net/fm10k/fm10k_ethdev.c| 6 +-
drivers/net/i40e/i40e_ethdev.c | 25 +-
drivers/net/i40e/i40e_ethdev_vf.c | 9 +-
drivers/net/virtio/virtio_ethdev.c | 7 +-
drivers/net/vmxnet3/vmxnet3_ethdev.c| 9 +-
lib/librte_eal/common/include/rte_pci_dev_ids.h | 420
14 files changed, 120 insertions(+), 466 deletions(-)
--
1.9.1
[dpdk-dev] [PATCH v4 01/10] eal: remove PCI device ids header from doxygen
This file is going to disappear, remove the doxygen parts that reference
various drivers and remove it from the doxygen index.
Signed-off-by: David Marchand
---
doc/api/doxy-api-index.md | 1 -
lib/librte_eal/common/include/rte_pci_dev_ids.h | 40 -
2 files changed, 41 deletions(-)
diff --git a/doc/api/doxy-api-index.md b/doc/api/doxy-api-index.md
index 5e7f024..2284a53 100644
--- a/doc/api/doxy-api-index.md
+++ b/doc/api/doxy-api-index.md
@@ -45,7 +45,6 @@ There are many libraries, so their headers may be grouped by
topics:
[vhost] (@ref rte_virtio_net.h),
[KNI](@ref rte_kni.h),
[PCI](@ref rte_pci.h),
- [PCI IDs](@ref rte_pci_dev_ids.h)
- **memory**:
[memseg] (@ref rte_memory.h),
diff --git a/lib/librte_eal/common/include/rte_pci_dev_ids.h
b/lib/librte_eal/common/include/rte_pci_dev_ids.h
index af39fbb..ecb877c 100644
--- a/lib/librte_eal/common/include/rte_pci_dev_ids.h
+++ b/lib/librte_eal/common/include/rte_pci_dev_ids.h
@@ -57,46 +57,6 @@
*
*/
-/**
- * @file
- *
- * This file contains a list of the PCI device IDs recognised by DPDK, which
- * can be used to fill out an array of structures describing the devices.
- *
- * Currently five families of devices are recognised: those supported by the
- * IGB driver, by EM driver, those supported by the IXGBE driver, those
- * supported by the BNXT driver, and by virtio driver which is a para
- * virtualization driver running in guest virtual machine. The inclusion of
- * these in an array built using this file depends on the definition of
- * RTE_PCI_DEV_ID_DECL_BNXT
- * RTE_PCI_DEV_ID_DECL_EM
- * RTE_PCI_DEV_ID_DECL_IGB
- * RTE_PCI_DEV_ID_DECL_IGBVF
- * RTE_PCI_DEV_ID_DECL_IXGBE
- * RTE_PCI_DEV_ID_DECL_IXGBEVF
- * RTE_PCI_DEV_ID_DECL_I40E
- * RTE_PCI_DEV_ID_DECL_I40EVF
- * RTE_PCI_DEV_ID_DECL_VIRTIO
- * at the time when this file is included.
- *
- * In order to populate an array, the user of this file must define this macro:
- * RTE_PCI_DEV_ID_DECL_IXGBE(vendorID, deviceID). For example:
- *
- * @code
- * struct device {
- * int vend;
- * int dev;
- * };
- *
- * struct device devices[] = {
- * #define RTE_PCI_DEV_ID_DECL_IXGBE(vendorID, deviceID) {vend, dev},
- * #include
- * };
- * @endcode
- *
- * Note that this file can be included multiple times within the same file.
- */
-
#ifndef RTE_PCI_DEV_ID_DECL_EM
#define RTE_PCI_DEV_ID_DECL_EM(vend, dev)
#endif
--
1.9.1
[dpdk-dev] [PATCH v4 02/10] net/e1000: move em PCI device ids to the driver
Reused defines from the driver and added a Intel vendor id macro for use by
igb later.
Used RTE_PCI_DEVICE in place of RTE_PCI_DEV_ID_DECL* stuff.
igb/igbvf is left as is, waiting for kni/ethtool cleanup.
Signed-off-by: David Marchand
---
Changes since v3:
- dropped all but em pci device ids
---
drivers/net/e1000/e1000_ethdev.h| 2 +
drivers/net/e1000/em_ethdev.c | 37 +-
lib/librte_eal/common/include/rte_pci_dev_ids.h | 148
3 files changed, 34 insertions(+), 153 deletions(-)
diff --git a/drivers/net/e1000/e1000_ethdev.h b/drivers/net/e1000/e1000_ethdev.h
index e8bf8da..6c25c8d 100644
--- a/drivers/net/e1000/e1000_ethdev.h
+++ b/drivers/net/e1000/e1000_ethdev.h
@@ -35,6 +35,8 @@
#define _E1000_ETHDEV_H_
#include
+#define E1000_INTEL_VENDOR_ID 0x8086
+
/* need update link, bit flag */
#define E1000_FLAG_NEED_LINK_UPDATE (uint32_t)(1 << 0)
#define E1000_FLAG_MAILBOX (uint32_t)(1 << 1)
diff --git a/drivers/net/e1000/em_ethdev.c b/drivers/net/e1000/em_ethdev.c
index 4de5eb2..ad104ed 100644
--- a/drivers/net/e1000/em_ethdev.c
+++ b/drivers/net/e1000/em_ethdev.c
@@ -137,11 +137,38 @@ static enum e1000_fc_mode em_fc_setting = e1000_fc_full;
* The set of PCI devices this driver supports
*/
static const struct rte_pci_id pci_id_em_map[] = {
-
-#define RTE_PCI_DEV_ID_DECL_EM(vend, dev) {RTE_PCI_DEVICE(vend, dev)},
-#include "rte_pci_dev_ids.h"
-
-{0},
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82540EM) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82545EM_COPPER) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82545EM_FIBER) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82546EB_COPPER) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82546EB_FIBER) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID,
E1000_DEV_ID_82546EB_QUAD_COPPER) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82571EB_COPPER) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82571EB_FIBER) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82571EB_SERDES) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID,
E1000_DEV_ID_82571EB_SERDES_DUAL) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID,
E1000_DEV_ID_82571EB_SERDES_QUAD) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID,
E1000_DEV_ID_82571EB_QUAD_COPPER) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID,
E1000_DEV_ID_82571PT_QUAD_COPPER) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID,
E1000_DEV_ID_82571EB_QUAD_FIBER) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID,
E1000_DEV_ID_82571EB_QUAD_COPPER_LP) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82572EI_COPPER) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82572EI_FIBER) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82572EI_SERDES) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82572EI) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82573L) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82574L) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82574LA) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_82583V) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_PCH_LPT_I217_LM) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_PCH_LPT_I217_V) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_PCH_LPTLP_I218_LM)
},
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_PCH_LPTLP_I218_V)
},
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_PCH_I218_LM2) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_PCH_I218_V2) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_PCH_I218_LM3) },
+ { RTE_PCI_DEVICE(E1000_INTEL_VENDOR_ID, E1000_DEV_ID_PCH_I218_V3) },
+ { .vendor_id = 0, /* sentinel */ },
};
static const struct eth_dev_ops eth_em_ops = {
diff --git a/lib/librte_eal/common/include/rte_pci_dev_ids.h
b/lib/librte_eal/common/include/rte_pci_dev_ids.h
index ecb877c..1b22adb 100644
--- a/lib/librte_eal/common/include/rte_pci_dev_ids.h
+++ b/lib/librte_eal/common/include/rte_pci_dev_ids.h
@@ -57,10 +57,6 @@
*
*/
-#ifndef RTE_PCI_DEV_ID_DECL_EM
-#define RTE_PCI_DEV_ID_DECL_EM(vend, dev)
-#endif
-
#ifndef RTE_PCI_DEV_ID_DECL_IGB
#define RTE_PCI_DEV_ID_DECL_IGB(vend, dev)
#endif
@@ -142,149 +138,6 @@
#define PCI_VENDOR_ID_BROADCOM 0x14E4
#endif
-/ Physical EM devices from e1000_hw.h /
-
-#define E1000_DEV_ID_825420x1000
-#define E1000_DEV_ID_82543GC_FIBER0x1001
-#define E1000_DEV_ID_82543GC_COPPER 0x1004
-#define E1000_DEV_ID_82544EI_COPPER 0x1008
-#define E1000_DEV_ID_82544EI_FIBER0x1009
-#define E1000_DEV_ID_82544GC_COPPER 0x100C
-#define E1000_DEV_ID_82544GC_LOM
[dpdk-dev] [PATCH v4 03/10] net/i40e: move PCI device ids to the driver
Reused defines from the driver.
Used RTE_PCI_DEVICE in place of RTE_PCI_DEV_ID_DECL* stuff.
Signed-off-by: David Marchand
---
Changes since v3
- added new pci ids from HEAD
---
drivers/net/i40e/i40e_ethdev.c | 25 +++--
drivers/net/i40e/i40e_ethdev_vf.c | 9 ++--
lib/librte_eal/common/include/rte_pci_dev_ids.h | 70 -
3 files changed, 28 insertions(+), 76 deletions(-)
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 31c2e11..daac236 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -454,9 +454,28 @@ static void i40e_set_default_mac_addr(struct rte_eth_dev
*dev,
static int i40e_dev_mtu_set(struct rte_eth_dev *dev, uint16_t mtu);
static const struct rte_pci_id pci_id_i40e_map[] = {
-#define RTE_PCI_DEV_ID_DECL_I40E(vend, dev) {RTE_PCI_DEVICE(vend, dev)},
-#include "rte_pci_dev_ids.h"
-{ .vendor_id = 0, /* sentinel */ },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_SFP_XL710) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_QEMU) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_KX_B) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_KX_C) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_QSFP_A) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_QSFP_B) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_QSFP_C) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_10G_BASE_T) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_20G_KR2) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_20G_KR2_A) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_10G_BASE_T4) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_25G_B) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_25G_SFP28) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_X722_A0) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_KX_X722) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_QSFP_X722) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_SFP_X722) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_1G_BASE_T_X722) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_10G_BASE_T_X722) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_SFP_I_X722) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_QSFP_I_X722) },
+ { .vendor_id = 0, /* sentinel */ },
};
static const struct eth_dev_ops i40e_eth_dev_ops = {
diff --git a/drivers/net/i40e/i40e_ethdev_vf.c
b/drivers/net/i40e/i40e_ethdev_vf.c
index 31547db..a616ae0 100644
--- a/drivers/net/i40e/i40e_ethdev_vf.c
+++ b/drivers/net/i40e/i40e_ethdev_vf.c
@@ -1110,9 +1110,12 @@ i40evf_get_link_status(struct rte_eth_dev *dev, struct
rte_eth_link *link)
}
static const struct rte_pci_id pci_id_i40evf_map[] = {
-#define RTE_PCI_DEV_ID_DECL_I40EVF(vend, dev) {RTE_PCI_DEVICE(vend, dev)},
-#include "rte_pci_dev_ids.h"
-{ .vendor_id = 0, /* sentinel */ },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_VF) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_VF_HV) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_X722_A0_VF) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_X722_VF) },
+ { RTE_PCI_DEVICE(I40E_INTEL_VENDOR_ID, I40E_DEV_ID_X722_VF_HV) },
+ { .vendor_id = 0, /* sentinel */ },
};
static inline int
diff --git a/lib/librte_eal/common/include/rte_pci_dev_ids.h
b/lib/librte_eal/common/include/rte_pci_dev_ids.h
index 1b22adb..30fcdee 100644
--- a/lib/librte_eal/common/include/rte_pci_dev_ids.h
+++ b/lib/librte_eal/common/include/rte_pci_dev_ids.h
@@ -73,14 +73,6 @@
#define RTE_PCI_DEV_ID_DECL_IXGBEVF(vend, dev)
#endif
-#ifndef RTE_PCI_DEV_ID_DECL_I40E
-#define RTE_PCI_DEV_ID_DECL_I40E(vend, dev)
-#endif
-
-#ifndef RTE_PCI_DEV_ID_DECL_I40EVF
-#define RTE_PCI_DEV_ID_DECL_I40EVF(vend, dev)
-#endif
-
#ifndef RTE_PCI_DEV_ID_DECL_VIRTIO
#define RTE_PCI_DEV_ID_DECL_VIRTIO(vend, dev)
#endif
@@ -341,52 +333,6 @@ RTE_PCI_DEV_ID_DECL_IXGBE(PCI_VENDOR_ID_INTEL,
IXGBE_DEV_ID_X550EM_X_KR)
RTE_PCI_DEV_ID_DECL_IXGBE(PCI_VENDOR_ID_INTEL, IXGBE_DEV_ID_82599_BYPASS)
#endif
-/*** Physical I40E devices from i40e_type.h */
-
-#define I40E_DEV_ID_SFP_XL710 0x1572
-#define I40E_DEV_ID_QEMU0x1574
-#define I40E_DEV_ID_KX_B0x1580
-#define I40E_DEV_ID_KX_C0x1581
-#define I40E_DEV_ID_QSFP_A 0x1583
-#define I40E_DEV_ID_QSFP_B 0x1584
-#define I40E_DEV_ID_QSFP_C 0x1585
-#define I40E_DEV_ID_10G_BASE_T 0x1586
-#define I40E_DEV_ID_20G_KR2 0x1587
-#define I40E_DEV_ID_20G_KR2_A 0x1588
-#define I40E_DEV_ID_10G_BASE_T4 0x1589
-#define I40E_DEV_ID_25G_B 0x158A
-#define I40E_DEV_ID_25G_SFP28 0x158B
-#define I40E_DE
[dpdk-dev] [PATCH v4 04/10] net/fm10k: move PCI device ids to the driver
Reused defines from the driver.
Used RTE_PCI_DEVICE in place of RTE_PCI_DEV_ID_DECL* stuff.
Signed-off-by: David Marchand
---
drivers/net/fm10k/fm10k_ethdev.c| 6 +++---
lib/librte_eal/common/include/rte_pci_dev_ids.h | 24
2 files changed, 3 insertions(+), 27 deletions(-)
diff --git a/drivers/net/fm10k/fm10k_ethdev.c b/drivers/net/fm10k/fm10k_ethdev.c
index 66be9c6..217853f 100644
--- a/drivers/net/fm10k/fm10k_ethdev.c
+++ b/drivers/net/fm10k/fm10k_ethdev.c
@@ -3049,9 +3049,9 @@ eth_fm10k_dev_uninit(struct rte_eth_dev *dev)
* and SRIOV-VF devices.
*/
static const struct rte_pci_id pci_id_fm10k_map[] = {
-#define RTE_PCI_DEV_ID_DECL_FM10K(vend, dev) { RTE_PCI_DEVICE(vend, dev) },
-#define RTE_PCI_DEV_ID_DECL_FM10KVF(vend, dev) { RTE_PCI_DEVICE(vend, dev) },
-#include "rte_pci_dev_ids.h"
+ { RTE_PCI_DEVICE(FM10K_INTEL_VENDOR_ID, FM10K_DEV_ID_PF) },
+ { RTE_PCI_DEVICE(FM10K_INTEL_VENDOR_ID, FM10K_DEV_ID_SDI_FM10420_QDA2)
},
+ { RTE_PCI_DEVICE(FM10K_INTEL_VENDOR_ID, FM10K_DEV_ID_VF) },
{ .vendor_id = 0, /* sentinel */ },
};
diff --git a/lib/librte_eal/common/include/rte_pci_dev_ids.h
b/lib/librte_eal/common/include/rte_pci_dev_ids.h
index 30fcdee..9e97d7c 100644
--- a/lib/librte_eal/common/include/rte_pci_dev_ids.h
+++ b/lib/librte_eal/common/include/rte_pci_dev_ids.h
@@ -81,14 +81,6 @@
#define RTE_PCI_DEV_ID_DECL_VMXNET3(vend, dev)
#endif
-#ifndef RTE_PCI_DEV_ID_DECL_FM10K
-#define RTE_PCI_DEV_ID_DECL_FM10K(vend, dev)
-#endif
-
-#ifndef RTE_PCI_DEV_ID_DECL_FM10KVF
-#define RTE_PCI_DEV_ID_DECL_FM10KVF(vend, dev)
-#endif
-
#ifndef RTE_PCI_DEV_ID_DECL_ENIC
#define RTE_PCI_DEV_ID_DECL_ENIC(vend, dev)
#endif
@@ -333,14 +325,6 @@ RTE_PCI_DEV_ID_DECL_IXGBE(PCI_VENDOR_ID_INTEL,
IXGBE_DEV_ID_X550EM_X_KR)
RTE_PCI_DEV_ID_DECL_IXGBE(PCI_VENDOR_ID_INTEL, IXGBE_DEV_ID_82599_BYPASS)
#endif
-/*** Physical FM10K devices from fm10k_type.h ***/
-
-#define FM10K_DEV_ID_PF 0x15A4
-#define FM10K_DEV_ID_SDI_FM10420_QDA2 0x15D0
-
-RTE_PCI_DEV_ID_DECL_FM10K(PCI_VENDOR_ID_INTEL, FM10K_DEV_ID_PF)
-RTE_PCI_DEV_ID_DECL_FM10K(PCI_VENDOR_ID_INTEL, FM10K_DEV_ID_SDI_FM10420_QDA2)
-
/** Virtual IGB devices from e1000_hw.h **/
#define E1000_DEV_ID_82576_VF 0x10CA
@@ -389,12 +373,6 @@ RTE_PCI_DEV_ID_DECL_VIRTIO(PCI_VENDOR_ID_QUMRANET,
QUMRANET_DEV_ID_VIRTIO)
RTE_PCI_DEV_ID_DECL_VMXNET3(PCI_VENDOR_ID_VMWARE, VMWARE_DEV_ID_VMXNET3)
-/*** Virtual FM10K devices from fm10k_type.h ***/
-
-#define FM10K_DEV_ID_VF 0x15A5
-
-RTE_PCI_DEV_ID_DECL_FM10KVF(PCI_VENDOR_ID_INTEL, FM10K_DEV_ID_VF)
-
/** Cisco VIC devices **/
#define PCI_DEVICE_ID_CISCO_VIC_ENET 0x0043 /* ethernet vnic */
@@ -483,6 +461,4 @@ RTE_PCI_DEV_ID_DECL_BNXT(PCI_VENDOR_ID_BROADCOM,
BROADCOM_DEV_ID_57314)
#undef RTE_PCI_DEV_ID_DECL_IXGBEVF
#undef RTE_PCI_DEV_ID_DECL_VIRTIO
#undef RTE_PCI_DEV_ID_DECL_VMXNET3
-#undef RTE_PCI_DEV_ID_DECL_FM10K
-#undef RTE_PCI_DEV_ID_DECL_FM10KVF
#undef RTE_PCI_DEV_ID_DECL_BNXT
--
1.9.1
[dpdk-dev] [PATCH v4 05/10] net/virtio: move PCI device ids to the driver
Reused defines from the driver.
Used RTE_PCI_DEVICE in place of RTE_PCI_DEV_ID_DECL* stuff.
Signed-off-by: David Marchand
Acked-by: Yuanhan Liu
---
drivers/net/virtio/virtio_ethdev.c | 7 ++-
lib/librte_eal/common/include/rte_pci_dev_ids.h | 16
2 files changed, 2 insertions(+), 21 deletions(-)
diff --git a/drivers/net/virtio/virtio_ethdev.c
b/drivers/net/virtio/virtio_ethdev.c
index 8467b3c..850e3ba 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -103,11 +103,8 @@ static int virtio_dev_queue_stats_mapping_set(
* The set of PCI devices this driver supports
*/
static const struct rte_pci_id pci_id_virtio_map[] = {
-
-#define RTE_PCI_DEV_ID_DECL_VIRTIO(vend, dev) {RTE_PCI_DEVICE(vend, dev)},
-#include "rte_pci_dev_ids.h"
-
-{ .vendor_id = 0, /* sentinel */ },
+ { RTE_PCI_DEVICE(VIRTIO_PCI_VENDORID, VIRTIO_PCI_DEVICEID_MIN) },
+ { .vendor_id = 0, /* sentinel */ },
};
struct rte_virtio_xstats_name_off {
diff --git a/lib/librte_eal/common/include/rte_pci_dev_ids.h
b/lib/librte_eal/common/include/rte_pci_dev_ids.h
index 9e97d7c..1c66784 100644
--- a/lib/librte_eal/common/include/rte_pci_dev_ids.h
+++ b/lib/librte_eal/common/include/rte_pci_dev_ids.h
@@ -73,10 +73,6 @@
#define RTE_PCI_DEV_ID_DECL_IXGBEVF(vend, dev)
#endif
-#ifndef RTE_PCI_DEV_ID_DECL_VIRTIO
-#define RTE_PCI_DEV_ID_DECL_VIRTIO(vend, dev)
-#endif
-
#ifndef RTE_PCI_DEV_ID_DECL_VMXNET3
#define RTE_PCI_DEV_ID_DECL_VMXNET3(vend, dev)
#endif
@@ -102,11 +98,6 @@
#define PCI_VENDOR_ID_INTEL 0x8086
#endif
-#ifndef PCI_VENDOR_ID_QUMRANET
-/** Vendor ID used by virtio devices */
-#define PCI_VENDOR_ID_QUMRANET 0x1AF4
-#endif
-
#ifndef PCI_VENDOR_ID_VMWARE
/** Vendor ID used by VMware devices */
#define PCI_VENDOR_ID_VMWARE 0x15AD
@@ -361,12 +352,6 @@ RTE_PCI_DEV_ID_DECL_IXGBEVF(PCI_VENDOR_ID_INTEL,
IXGBE_DEV_ID_X550EM_A_VF_HV)
RTE_PCI_DEV_ID_DECL_IXGBEVF(PCI_VENDOR_ID_INTEL, IXGBE_DEV_ID_X550EM_X_VF)
RTE_PCI_DEV_ID_DECL_IXGBEVF(PCI_VENDOR_ID_INTEL, IXGBE_DEV_ID_X550EM_X_VF_HV)
-/** Virtio devices from virtio.h **/
-
-#define QUMRANET_DEV_ID_VIRTIO 0x1000
-
-RTE_PCI_DEV_ID_DECL_VIRTIO(PCI_VENDOR_ID_QUMRANET, QUMRANET_DEV_ID_VIRTIO)
-
/** VMware VMXNET3 devices **/
#define VMWARE_DEV_ID_VMXNET3 0x07B0
@@ -459,6 +444,5 @@ RTE_PCI_DEV_ID_DECL_BNXT(PCI_VENDOR_ID_BROADCOM,
BROADCOM_DEV_ID_57314)
#undef RTE_PCI_DEV_ID_DECL_IGBVF
#undef RTE_PCI_DEV_ID_DECL_IXGBE
#undef RTE_PCI_DEV_ID_DECL_IXGBEVF
-#undef RTE_PCI_DEV_ID_DECL_VIRTIO
#undef RTE_PCI_DEV_ID_DECL_VMXNET3
#undef RTE_PCI_DEV_ID_DECL_BNXT
--
1.9.1
[dpdk-dev] [PATCH v4 06/10] net/vmxnet3: move PCI device ids to the driver
Moved vmware device ids macro since the driver had no such information.
Used RTE_PCI_DEVICE in place of RTE_PCI_DEV_ID_DECL* stuff.
Signed-off-by: David Marchand
---
drivers/net/vmxnet3/vmxnet3_ethdev.c| 9 -
lib/librte_eal/common/include/rte_pci_dev_ids.h | 16
2 files changed, 4 insertions(+), 21 deletions(-)
diff --git a/drivers/net/vmxnet3/vmxnet3_ethdev.c
b/drivers/net/vmxnet3/vmxnet3_ethdev.c
index 8da4449..5874215 100644
--- a/drivers/net/vmxnet3/vmxnet3_ethdev.c
+++ b/drivers/net/vmxnet3/vmxnet3_ethdev.c
@@ -100,12 +100,11 @@ static void vmxnet3_process_events(struct vmxnet3_hw *);
/*
* The set of PCI devices this driver supports
*/
+#define VMWARE_PCI_VENDOR_ID 0x15AD
+#define VMWARE_DEV_ID_VMXNET3 0x07B0
static const struct rte_pci_id pci_id_vmxnet3_map[] = {
-
-#define RTE_PCI_DEV_ID_DECL_VMXNET3(vend, dev) {RTE_PCI_DEVICE(vend, dev)},
-#include "rte_pci_dev_ids.h"
-
-{ .vendor_id = 0, /* sentinel */ },
+ { RTE_PCI_DEVICE(VMWARE_PCI_VENDOR_ID, VMWARE_DEV_ID_VMXNET3) },
+ { .vendor_id = 0, /* sentinel */ },
};
static const struct eth_dev_ops vmxnet3_eth_dev_ops = {
diff --git a/lib/librte_eal/common/include/rte_pci_dev_ids.h
b/lib/librte_eal/common/include/rte_pci_dev_ids.h
index 1c66784..a4aba6d 100644
--- a/lib/librte_eal/common/include/rte_pci_dev_ids.h
+++ b/lib/librte_eal/common/include/rte_pci_dev_ids.h
@@ -73,10 +73,6 @@
#define RTE_PCI_DEV_ID_DECL_IXGBEVF(vend, dev)
#endif
-#ifndef RTE_PCI_DEV_ID_DECL_VMXNET3
-#define RTE_PCI_DEV_ID_DECL_VMXNET3(vend, dev)
-#endif
-
#ifndef RTE_PCI_DEV_ID_DECL_ENIC
#define RTE_PCI_DEV_ID_DECL_ENIC(vend, dev)
#endif
@@ -98,11 +94,6 @@
#define PCI_VENDOR_ID_INTEL 0x8086
#endif
-#ifndef PCI_VENDOR_ID_VMWARE
-/** Vendor ID used by VMware devices */
-#define PCI_VENDOR_ID_VMWARE 0x15AD
-#endif
-
#ifndef PCI_VENDOR_ID_CISCO
/** Vendor ID used by Cisco VIC devices */
#define PCI_VENDOR_ID_CISCO 0x1137
@@ -352,12 +343,6 @@ RTE_PCI_DEV_ID_DECL_IXGBEVF(PCI_VENDOR_ID_INTEL,
IXGBE_DEV_ID_X550EM_A_VF_HV)
RTE_PCI_DEV_ID_DECL_IXGBEVF(PCI_VENDOR_ID_INTEL, IXGBE_DEV_ID_X550EM_X_VF)
RTE_PCI_DEV_ID_DECL_IXGBEVF(PCI_VENDOR_ID_INTEL, IXGBE_DEV_ID_X550EM_X_VF_HV)
-/** VMware VMXNET3 devices **/
-
-#define VMWARE_DEV_ID_VMXNET3 0x07B0
-
-RTE_PCI_DEV_ID_DECL_VMXNET3(PCI_VENDOR_ID_VMWARE, VMWARE_DEV_ID_VMXNET3)
-
/** Cisco VIC devices **/
#define PCI_DEVICE_ID_CISCO_VIC_ENET 0x0043 /* ethernet vnic */
@@ -444,5 +429,4 @@ RTE_PCI_DEV_ID_DECL_BNXT(PCI_VENDOR_ID_BROADCOM,
BROADCOM_DEV_ID_57314)
#undef RTE_PCI_DEV_ID_DECL_IGBVF
#undef RTE_PCI_DEV_ID_DECL_IXGBE
#undef RTE_PCI_DEV_ID_DECL_IXGBEVF
-#undef RTE_PCI_DEV_ID_DECL_VMXNET3
#undef RTE_PCI_DEV_ID_DECL_BNXT
--
1.9.1
[dpdk-dev] [PATCH v4 07/10] net/enic: move PCI device ids to the driver
Moved cisco vendor id since the driver had no such information.
Used RTE_PCI_DEVICE in place of RTE_PCI_DEV_ID_DECL* stuff.
Signed-off-by: David Marchand
---
drivers/net/enic/enic_ethdev.c | 12
lib/librte_eal/common/include/rte_pci_dev_ids.h | 17 -
2 files changed, 4 insertions(+), 25 deletions(-)
diff --git a/drivers/net/enic/enic_ethdev.c b/drivers/net/enic/enic_ethdev.c
index 633e431..3c87b49 100644
--- a/drivers/net/enic/enic_ethdev.c
+++ b/drivers/net/enic/enic_ethdev.c
@@ -57,15 +57,11 @@
/*
* The set of PCI devices this driver supports
*/
+#define CISCO_PCI_VENDOR_ID 0x1137
static const struct rte_pci_id pci_id_enic_map[] = {
-#define RTE_PCI_DEV_ID_DECL_ENIC(vend, dev) {RTE_PCI_DEVICE(vend, dev)},
-#ifndef PCI_VENDOR_ID_CISCO
-#define PCI_VENDOR_ID_CISCO0x1137
-#endif
-#include "rte_pci_dev_ids.h"
-RTE_PCI_DEV_ID_DECL_ENIC(PCI_VENDOR_ID_CISCO, PCI_DEVICE_ID_CISCO_VIC_ENET)
-RTE_PCI_DEV_ID_DECL_ENIC(PCI_VENDOR_ID_CISCO, PCI_DEVICE_ID_CISCO_VIC_ENET_VF)
-{.vendor_id = 0, /* Sentinal */},
+ { RTE_PCI_DEVICE(CISCO_PCI_VENDOR_ID, PCI_DEVICE_ID_CISCO_VIC_ENET) },
+ { RTE_PCI_DEVICE(CISCO_PCI_VENDOR_ID, PCI_DEVICE_ID_CISCO_VIC_ENET_VF)
},
+ {.vendor_id = 0, /* sentinel */},
};
static int
diff --git a/lib/librte_eal/common/include/rte_pci_dev_ids.h
b/lib/librte_eal/common/include/rte_pci_dev_ids.h
index a4aba6d..ef85d08 100644
--- a/lib/librte_eal/common/include/rte_pci_dev_ids.h
+++ b/lib/librte_eal/common/include/rte_pci_dev_ids.h
@@ -73,10 +73,6 @@
#define RTE_PCI_DEV_ID_DECL_IXGBEVF(vend, dev)
#endif
-#ifndef RTE_PCI_DEV_ID_DECL_ENIC
-#define RTE_PCI_DEV_ID_DECL_ENIC(vend, dev)
-#endif
-
#ifndef RTE_PCI_DEV_ID_DECL_BNX2X
#define RTE_PCI_DEV_ID_DECL_BNX2X(vend, dev)
#endif
@@ -94,11 +90,6 @@
#define PCI_VENDOR_ID_INTEL 0x8086
#endif
-#ifndef PCI_VENDOR_ID_CISCO
-/** Vendor ID used by Cisco VIC devices */
-#define PCI_VENDOR_ID_CISCO 0x1137
-#endif
-
#ifndef PCI_VENDOR_ID_BROADCOM
/** Vendor ID used by Broadcom devices */
#define PCI_VENDOR_ID_BROADCOM 0x14E4
@@ -343,14 +334,6 @@ RTE_PCI_DEV_ID_DECL_IXGBEVF(PCI_VENDOR_ID_INTEL,
IXGBE_DEV_ID_X550EM_A_VF_HV)
RTE_PCI_DEV_ID_DECL_IXGBEVF(PCI_VENDOR_ID_INTEL, IXGBE_DEV_ID_X550EM_X_VF)
RTE_PCI_DEV_ID_DECL_IXGBEVF(PCI_VENDOR_ID_INTEL, IXGBE_DEV_ID_X550EM_X_VF_HV)
-/** Cisco VIC devices **/
-
-#define PCI_DEVICE_ID_CISCO_VIC_ENET 0x0043 /* ethernet vnic */
-#define PCI_DEVICE_ID_CISCO_VIC_ENET_VF 0x0071 /* enet SRIOV VF */
-
-RTE_PCI_DEV_ID_DECL_ENIC(PCI_VENDOR_ID_CISCO, PCI_DEVICE_ID_CISCO_VIC_ENET)
-RTE_PCI_DEV_ID_DECL_ENIC(PCI_VENDOR_ID_CISCO, PCI_DEVICE_ID_CISCO_VIC_ENET_VF)
-
/** QLogic devices **/
/* Broadcom/QLogic BNX2X */
--
1.9.1
[dpdk-dev] [PATCH v4 08/10] net/bnx2x: move PCI device ids to the driver
Reused defines from the driver and moved broadcom vendor id macro.
Used RTE_PCI_DEVICE in place of RTE_PCI_DEV_ID_DECL* stuff.
Signed-off-by: David Marchand
---
drivers/net/bnx2x/bnx2x.c | 3 +-
drivers/net/bnx2x/bnx2x_ethdev.c| 21 --
lib/librte_eal/common/include/rte_pci_dev_ids.h | 55 -
3 files changed, 18 insertions(+), 61 deletions(-)
diff --git a/drivers/net/bnx2x/bnx2x.c b/drivers/net/bnx2x/bnx2x.c
index 10859c1..95fbad8 100644
--- a/drivers/net/bnx2x/bnx2x.c
+++ b/drivers/net/bnx2x/bnx2x.c
@@ -22,7 +22,6 @@
#include "ecore_init_ops.h"
#include "rte_version.h"
-#include "rte_pci_dev_ids.h"
#include
#include
@@ -9572,7 +9571,7 @@ void bnx2x_load_firmware(struct bnx2x_softc *sc)
int f;
struct stat st;
- fwname = sc->devinfo.device_id == BNX2X_DEV_ID_57711
+ fwname = sc->devinfo.device_id == CHIP_NUM_57711
? FW_NAME_57711 : FW_NAME_57810;
f = open(fwname, O_RDONLY);
if (f < 0) {
diff --git a/drivers/net/bnx2x/bnx2x_ethdev.c b/drivers/net/bnx2x/bnx2x_ethdev.c
index 84c9662..c8d2bf2 100644
--- a/drivers/net/bnx2x/bnx2x_ethdev.c
+++ b/drivers/net/bnx2x/bnx2x_ethdev.c
@@ -16,15 +16,28 @@
/*
* The set of PCI devices this driver supports
*/
+#define BROADCOM_PCI_VENDOR_ID 0x14E4
static struct rte_pci_id pci_id_bnx2x_map[] = {
-#define RTE_PCI_DEV_ID_DECL_BNX2X(vend, dev) {RTE_PCI_DEVICE(vend, dev)},
-#include "rte_pci_dev_ids.h"
+ { RTE_PCI_DEVICE(BROADCOM_PCI_VENDOR_ID, CHIP_NUM_57800) },
+ { RTE_PCI_DEVICE(BROADCOM_PCI_VENDOR_ID, CHIP_NUM_57711) },
+ { RTE_PCI_DEVICE(BROADCOM_PCI_VENDOR_ID, CHIP_NUM_57810) },
+ { RTE_PCI_DEVICE(BROADCOM_PCI_VENDOR_ID, CHIP_NUM_57811) },
+ { RTE_PCI_DEVICE(BROADCOM_PCI_VENDOR_ID, CHIP_NUM_57840_OBS) },
+ { RTE_PCI_DEVICE(BROADCOM_PCI_VENDOR_ID, CHIP_NUM_57840_4_10) },
+ { RTE_PCI_DEVICE(BROADCOM_PCI_VENDOR_ID, CHIP_NUM_57840_2_20) },
+#ifdef RTE_LIBRTE_BNX2X_MF_SUPPORT
+ { RTE_PCI_DEVICE(BROADCOM_PCI_VENDOR_ID, CHIP_NUM_57810_MF) },
+ { RTE_PCI_DEVICE(BROADCOM_PCI_VENDOR_ID, CHIP_NUM_57811_MF) },
+ { RTE_PCI_DEVICE(BROADCOM_PCI_VENDOR_ID, CHIP_NUM_57840_MF) },
+#endif
{ .vendor_id = 0, }
};
static struct rte_pci_id pci_id_bnx2xvf_map[] = {
-#define RTE_PCI_DEV_ID_DECL_BNX2XVF(vend, dev) {RTE_PCI_DEVICE(vend, dev)},
-#include "rte_pci_dev_ids.h"
+ { RTE_PCI_DEVICE(BROADCOM_PCI_VENDOR_ID, CHIP_NUM_57800_VF) },
+ { RTE_PCI_DEVICE(BROADCOM_PCI_VENDOR_ID, CHIP_NUM_57810_VF) },
+ { RTE_PCI_DEVICE(BROADCOM_PCI_VENDOR_ID, CHIP_NUM_57811_VF) },
+ { RTE_PCI_DEVICE(BROADCOM_PCI_VENDOR_ID, CHIP_NUM_57840_VF) },
{ .vendor_id = 0, }
};
diff --git a/lib/librte_eal/common/include/rte_pci_dev_ids.h
b/lib/librte_eal/common/include/rte_pci_dev_ids.h
index ef85d08..fd2eb5d 100644
--- a/lib/librte_eal/common/include/rte_pci_dev_ids.h
+++ b/lib/librte_eal/common/include/rte_pci_dev_ids.h
@@ -73,14 +73,6 @@
#define RTE_PCI_DEV_ID_DECL_IXGBEVF(vend, dev)
#endif
-#ifndef RTE_PCI_DEV_ID_DECL_BNX2X
-#define RTE_PCI_DEV_ID_DECL_BNX2X(vend, dev)
-#endif
-
-#ifndef RTE_PCI_DEV_ID_DECL_BNX2XVF
-#define RTE_PCI_DEV_ID_DECL_BNX2XVF(vend, dev)
-#endif
-
#ifndef RTE_PCI_DEV_ID_DECL_BNXT
#define RTE_PCI_DEV_ID_DECL_BNXT(vend, dev)
#endif
@@ -334,51 +326,6 @@ RTE_PCI_DEV_ID_DECL_IXGBEVF(PCI_VENDOR_ID_INTEL,
IXGBE_DEV_ID_X550EM_A_VF_HV)
RTE_PCI_DEV_ID_DECL_IXGBEVF(PCI_VENDOR_ID_INTEL, IXGBE_DEV_ID_X550EM_X_VF)
RTE_PCI_DEV_ID_DECL_IXGBEVF(PCI_VENDOR_ID_INTEL, IXGBE_DEV_ID_X550EM_X_VF_HV)
-/** QLogic devices **/
-
-/* Broadcom/QLogic BNX2X */
-#define BNX2X_DEV_ID_57710 0x164e
-#define BNX2X_DEV_ID_57711 0x164f
-#define BNX2X_DEV_ID_57711E0x1650
-#define BNX2X_DEV_ID_57712 0x1662
-#define BNX2X_DEV_ID_57712_MF 0x1663
-#define BNX2X_DEV_ID_57712_VF 0x166f
-#define BNX2X_DEV_ID_57713 0x1651
-#define BNX2X_DEV_ID_57713E0x1652
-#define BNX2X_DEV_ID_57800 0x168a
-#define BNX2X_DEV_ID_57800_MF 0x16a5
-#define BNX2X_DEV_ID_57800_VF 0x16a9
-#define BNX2X_DEV_ID_57810 0x168e
-#define BNX2X_DEV_ID_57810_MF 0x16ae
-#define BNX2X_DEV_ID_57810_VF 0x16af
-#define BNX2X_DEV_ID_57811 0x163d
-#define BNX2X_DEV_ID_57811_MF 0x163e
-#define BNX2X_DEV_ID_57811_VF 0x163f
-
-#define BNX2X_DEV_ID_57840_OBS 0x168d
-#define BNX2X_DEV_ID_57840_OBS_MF 0x16ab
-#define BNX2X_DEV_ID_57840_4_100x16a1
-#define BNX2X_DEV_ID_57840_2_200x16a2
-#define BNX2X_DEV_ID_57840_MF 0x16a4
-#define BNX2X_DEV_ID_57840_VF 0x16ad
-
-RTE_PCI_DEV_ID_DECL_BNX2X(PCI_VENDOR_ID_BROADCOM, BNX2X_DEV_ID_57800)
-RTE_PCI_DEV_ID_DECL_BNX2XVF(PCI_VENDOR_ID_BROADCOM, BNX2X_DEV_ID_57800_VF)
-RTE_PCI_DEV_ID_DECL_BNX2X(PCI_VENDOR_ID_BROADCOM, BNX2X_DEV_ID_57711)
-RTE_PCI_DEV_ID_DECL_BNX2X(PCI_VENDOR_ID_BROADCOM, BNX2X_DEV_ID_57810)
-RTE_PCI_DEV_ID_DECL_BNX2XVF(PCI_VENDOR_ID_BROAD
[dpdk-dev] [PATCH v4 09/10] net/bnxt: move PCI device ids to the driver
Moved defines since the driver had no such information.
Used RTE_PCI_DEVICE in place of RTE_PCI_DEV_ID_DECL* stuff.
Signed-off-by: David Marchand
---
drivers/net/bnxt/bnxt_ethdev.c | 27 +---
lib/librte_eal/common/include/rte_pci_dev_ids.h | 34 -
2 files changed, 24 insertions(+), 37 deletions(-)
diff --git a/drivers/net/bnxt/bnxt_ethdev.c b/drivers/net/bnxt/bnxt_ethdev.c
index 9a2123e..3795fac 100644
--- a/drivers/net/bnxt/bnxt_ethdev.c
+++ b/drivers/net/bnxt/bnxt_ethdev.c
@@ -56,10 +56,31 @@
static const char bnxt_version[] =
"Broadcom Cumulus driver " DRV_MODULE_NAME "\n";
+#define PCI_VENDOR_ID_BROADCOM 0x14E4
+
+#define BROADCOM_DEV_ID_57301 0x16c8
+#define BROADCOM_DEV_ID_57302 0x16c9
+#define BROADCOM_DEV_ID_57304_PF 0x16ca
+#define BROADCOM_DEV_ID_57304_VF 0x16cb
+#define BROADCOM_DEV_ID_57402 0x16d0
+#define BROADCOM_DEV_ID_57404 0x16d1
+#define BROADCOM_DEV_ID_57406_PF 0x16d2
+#define BROADCOM_DEV_ID_57406_VF 0x16d3
+#define BROADCOM_DEV_ID_57406_MF 0x16d4
+#define BROADCOM_DEV_ID_57314 0x16df
+
static struct rte_pci_id bnxt_pci_id_map[] = {
-#define RTE_PCI_DEV_ID_DECL_BNXT(vend, dev) {RTE_PCI_DEVICE(vend, dev)},
-#include "rte_pci_dev_ids.h"
- {.device_id = 0},
+ { RTE_PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, BROADCOM_DEV_ID_57301) },
+ { RTE_PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, BROADCOM_DEV_ID_57302) },
+ { RTE_PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, BROADCOM_DEV_ID_57304_PF) },
+ { RTE_PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, BROADCOM_DEV_ID_57304_VF) },
+ { RTE_PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, BROADCOM_DEV_ID_57402) },
+ { RTE_PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, BROADCOM_DEV_ID_57404) },
+ { RTE_PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, BROADCOM_DEV_ID_57406_PF) },
+ { RTE_PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, BROADCOM_DEV_ID_57406_VF) },
+ { RTE_PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, BROADCOM_DEV_ID_57406_MF) },
+ { RTE_PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, BROADCOM_DEV_ID_57314) },
+ { .vendor_id = 0, /* sentinel */ },
};
#define BNXT_ETH_RSS_SUPPORT ( \
diff --git a/lib/librte_eal/common/include/rte_pci_dev_ids.h
b/lib/librte_eal/common/include/rte_pci_dev_ids.h
index fd2eb5d..6ec8ae8 100644
--- a/lib/librte_eal/common/include/rte_pci_dev_ids.h
+++ b/lib/librte_eal/common/include/rte_pci_dev_ids.h
@@ -73,20 +73,11 @@
#define RTE_PCI_DEV_ID_DECL_IXGBEVF(vend, dev)
#endif
-#ifndef RTE_PCI_DEV_ID_DECL_BNXT
-#define RTE_PCI_DEV_ID_DECL_BNXT(vend, dev)
-#endif
-
#ifndef PCI_VENDOR_ID_INTEL
/** Vendor ID used by Intel devices */
#define PCI_VENDOR_ID_INTEL 0x8086
#endif
-#ifndef PCI_VENDOR_ID_BROADCOM
-/** Vendor ID used by Broadcom devices */
-#define PCI_VENDOR_ID_BROADCOM 0x14E4
-#endif
-
/ Physical IGB devices from e1000_hw.h
/
#define E1000_DEV_ID_82576 0x10C9
@@ -326,30 +317,6 @@ RTE_PCI_DEV_ID_DECL_IXGBEVF(PCI_VENDOR_ID_INTEL,
IXGBE_DEV_ID_X550EM_A_VF_HV)
RTE_PCI_DEV_ID_DECL_IXGBEVF(PCI_VENDOR_ID_INTEL, IXGBE_DEV_ID_X550EM_X_VF)
RTE_PCI_DEV_ID_DECL_IXGBEVF(PCI_VENDOR_ID_INTEL, IXGBE_DEV_ID_X550EM_X_VF_HV)
-/** Broadcom bnxt devices **/
-
-#define BROADCOM_DEV_ID_57301 0x16c8
-#define BROADCOM_DEV_ID_57302 0x16c9
-#define BROADCOM_DEV_ID_57304_PF 0x16ca
-#define BROADCOM_DEV_ID_57304_VF 0x16cb
-#define BROADCOM_DEV_ID_57402 0x16d0
-#define BROADCOM_DEV_ID_57404 0x16d1
-#define BROADCOM_DEV_ID_57406_PF 0x16d2
-#define BROADCOM_DEV_ID_57406_VF 0x16d3
-#define BROADCOM_DEV_ID_57406_MF 0x16d4
-#define BROADCOM_DEV_ID_57314 0x16df
-
-RTE_PCI_DEV_ID_DECL_BNXT(PCI_VENDOR_ID_BROADCOM, BROADCOM_DEV_ID_57301)
-RTE_PCI_DEV_ID_DECL_BNXT(PCI_VENDOR_ID_BROADCOM, BROADCOM_DEV_ID_57302)
-RTE_PCI_DEV_ID_DECL_BNXT(PCI_VENDOR_ID_BROADCOM, BROADCOM_DEV_ID_57304_PF)
-RTE_PCI_DEV_ID_DECL_BNXT(PCI_VENDOR_ID_BROADCOM, BROADCOM_DEV_ID_57304_VF)
-RTE_PCI_DEV_ID_DECL_BNXT(PCI_VENDOR_ID_BROADCOM, BROADCOM_DEV_ID_57402)
-RTE_PCI_DEV_ID_DECL_BNXT(PCI_VENDOR_ID_BROADCOM, BROADCOM_DEV_ID_57404)
-RTE_PCI_DEV_ID_DECL_BNXT(PCI_VENDOR_ID_BROADCOM, BROADCOM_DEV_ID_57406_PF)
-RTE_PCI_DEV_ID_DECL_BNXT(PCI_VENDOR_ID_BROADCOM, BROADCOM_DEV_ID_57406_VF)
-RTE_PCI_DEV_ID_DECL_BNXT(PCI_VENDOR_ID_BROADCOM, BROADCOM_DEV_ID_57406_MF)
-RTE_PCI_DEV_ID_DECL_BNXT(PCI_VENDOR_ID_BROADCOM, BROADCOM_DEV_ID_57314)
-
/*
* Undef all RTE_PCI_DEV_ID_DECL_* here.
*/
@@ -357,4 +324,3 @@ RTE_PCI_DEV_ID_DECL_BNXT(PCI_VENDOR_ID_BROADCOM,
BROADCOM_DEV_ID_57314)
#undef RTE_PCI_DEV_ID_DECL_IGBVF
#undef RTE_PCI_DEV_ID_DECL_IXGBE
#undef RTE_PCI_DEV_ID_DECL_IXGBEVF
-#undef RTE_PCI_DEV_ID_DECL_BNXT
--
1.9.1
[dpdk-dev] [PATCH v4 10/10] net/ena: remove unneeded PCI macro
I suppose this is a remnant of rte_pci_dev_ids.h, just remove this.
Signed-off-by: David Marchand
---
drivers/net/ena/ena_ethdev.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ena/ena_ethdev.c b/drivers/net/ena/ena_ethdev.c
index f1b5e64..ac0803d 100644
--- a/drivers/net/ena/ena_ethdev.c
+++ b/drivers/net/ena/ena_ethdev.c
@@ -169,10 +169,9 @@ static const struct ena_stats ena_stats_ena_com_strings[]
= {
#define PCI_DEVICE_ID_ENA_LLQ_VF 0xEC21
static struct rte_pci_id pci_id_ena_map[] = {
-#define RTE_PCI_DEV_ID_DECL_ENA(vend, dev) {RTE_PCI_DEVICE(vend, dev)},
- RTE_PCI_DEV_ID_DECL_ENA(PCI_VENDOR_ID_AMAZON, PCI_DEVICE_ID_ENA_VF)
- RTE_PCI_DEV_ID_DECL_ENA(PCI_VENDOR_ID_AMAZON, PCI_DEVICE_ID_ENA_LLQ_VF)
- {.device_id = 0},
+ { RTE_PCI_DEVICE(PCI_VENDOR_ID_AMAZON, PCI_DEVICE_ID_ENA_VF) },
+ { RTE_PCI_DEVICE(PCI_VENDOR_ID_AMAZON, PCI_DEVICE_ID_ENA_LLQ_VF) },
+ { .device_id = 0 },
};
static int ena_device_init(struct ena_com_dev *ena_dev,
--
1.9.1
[dpdk-dev] [PATCH v2 0/2] examples/ipsec_secgw: add configuration file support
This patchset adds the configuration file supported to ipsec_secgw sample application. Two sample configuration files, ep0.cfg and ep1.cfg are also added to show how to configure two systems back-to-back that would forward traffic through an IPsec tunnel v2 changes: - fix configuration file parsing error. - update doc to remove whitespace tailing errors. Fan Zhang (2): examples/ipsec-secgw: add configuration file support examples/ipsec-secgw: add sample configuration files doc/guides/sample_app_ug/ipsec_secgw.rst | 809 --- examples/ipsec-secgw/Makefile| 1 + examples/ipsec-secgw/ep0.cfg | 119 + examples/ipsec-secgw/ep1.cfg | 119 + examples/ipsec-secgw/ipsec-secgw.c | 58 +-- examples/ipsec-secgw/ipsec.h | 8 +- examples/ipsec-secgw/parser.c| 602 +++ examples/ipsec-secgw/parser.h| 116 + examples/ipsec-secgw/rt.c| 255 +- examples/ipsec-secgw/sa.c| 462 ++ examples/ipsec-secgw/sp4.c | 539 +++- examples/ipsec-secgw/sp6.c | 540 ++--- 12 files changed, 2357 insertions(+), 1271 deletions(-) create mode 100644 examples/ipsec-secgw/ep0.cfg create mode 100644 examples/ipsec-secgw/ep1.cfg create mode 100644 examples/ipsec-secgw/parser.c create mode 100644 examples/ipsec-secgw/parser.h -- 2.5.5
[dpdk-dev] [PATCH v2 1/2] examples/ipsec-secgw: add configuration file support
This patch adds the configuration file support to ipsec_secgw sample application. Instead of hard-coded rules, the users can specify their own SP, SA, and routing rules in the configuration file. An command line option "-f" is added to pass the configuration file location to the application. Configuration item formats: SP rule format: sp esp \ SA rule format: sa Routing rule format: rt Signed-off-by: Fan Zhang --- doc/guides/sample_app_ug/ipsec_secgw.rst | 809 --- examples/ipsec-secgw/Makefile| 1 + examples/ipsec-secgw/ipsec-secgw.c | 58 +-- examples/ipsec-secgw/ipsec.h | 8 +- examples/ipsec-secgw/parser.c| 602 +++ examples/ipsec-secgw/parser.h| 116 + examples/ipsec-secgw/rt.c| 255 +- examples/ipsec-secgw/sa.c| 462 ++ examples/ipsec-secgw/sp4.c | 539 +++- examples/ipsec-secgw/sp6.c | 540 ++--- 10 files changed, 2119 insertions(+), 1271 deletions(-) create mode 100644 examples/ipsec-secgw/parser.c create mode 100644 examples/ipsec-secgw/parser.h diff --git a/doc/guides/sample_app_ug/ipsec_secgw.rst b/doc/guides/sample_app_ug/ipsec_secgw.rst index fcb33c2..2757df5 100644 --- a/doc/guides/sample_app_ug/ipsec_secgw.rst +++ b/doc/guides/sample_app_ug/ipsec_secgw.rst @@ -122,7 +122,7 @@ The application has a number of command line options:: -p PORTMASK -P -u PORTMASK --config (port,queue,lcore)[,(port,queue,lcore] --single-sa SAIDX - --ep0|--ep1 +-f CONFIG_FILE_PATH Where: @@ -142,14 +142,11 @@ Where: on both Inbound and Outbound. This option is meant for debugging/performance purposes. -* ``--ep0``: configure the app as Endpoint 0. +* ``-f CONFIG_FILE_PATH``: the full path of text-based file containing all +configuration items for running the application (See Configuration file +syntax section below). ``-f CONFIG_FILE_PATH`` **must** be specified. +**ONLY** the UNIX format configuration file is accepted. -* ``--ep1``: configure the app as Endpoint 1. - -Either one of ``--ep0`` or ``--ep1`` **must** be specified. -The main purpose of these options is to easily configure two systems -back-to-back that would forward traffic through an IPsec tunnel (see -:ref:`figure_ipsec_endpoints`). The mapping of lcores to port/queues is similar to other l3fwd applications. @@ -157,7 +154,8 @@ For example, given the following command line:: ./build/ipsec-secgw -l 20,21 -n 4 --socket-mem 0,2048 \ --vdev "cryptodev_null_pmd" -- -p 0xf -P -u 0x3 \ - --config="(0,0,20),(1,0,20),(2,0,21),(3,0,21)" --ep0 \ + --config="(0,0,20),(1,0,20),(2,0,21),(3,0,21)" \ + -f /path/to/config_file \ where each options means: @@ -194,8 +192,12 @@ where each options means: | | | | | +--+---+---+---+ -* The ``--ep0`` options configures the app with a given set of SP, SA and Routing -entries as explained below in more detail. +* The ``-f /path/to/config_file`` option enables the application read and +parse the configuration file specified, and configures the application +with a given set of SP, SA and Routing entries accordingly. The syntax of +the configuration file will be explained below in more detail. Please +**note** the parser only accepts UNIX format text file. Other formats +such as DOS/MAC format will cause a parse error. Refer to the *DPDK Getting Started Guide* for general information on running applications and the Environment Abstraction Layer (EAL) options. @@ -219,496 +221,321 @@ For example, something like the following command line: --vdev "cryptodev_aesni_mb_pmd" --vdev "cryptodev_null_pmd" \ -- \ -p 0xf -P -u 0x3 --config="(0,0,20),(1,0,20),(2,0,21),(3,0,21)" \ ---ep0 +-f sample.cfg Configurations -- -The following sections provide some details on the default values used to -initialize the SP, SA and Routing tables. -Currently all configuration information is hard coded into the application. +The following sections provide the syntax of configurations to initialize +your SP, SA and Routing tables. +Configurations shall be specified in the configuration file to be passed to +the application. The file is then parsed by the application. The successful +parsing will result in the appropriate rules being applied to the tables +accordingly. -The following image illustrate a few of the concepts regarding IPSec, such -as protected/unprotected and inbound/outbound traffic, from the
[dpdk-dev] [PATCH v2 2/2] examples/ipsec-secgw: add sample configuration files
This patch adds two sample configuration files to ipsec-secgw sample application. The sample configuration files shows how to set-up systems back-to-back that would forward traffic through an IPsec tunnel. Signed-off-by: Fan Zhang --- examples/ipsec-secgw/ep0.cfg | 119 +++ examples/ipsec-secgw/ep1.cfg | 119 +++ 2 files changed, 238 insertions(+) create mode 100644 examples/ipsec-secgw/ep0.cfg create mode 100644 examples/ipsec-secgw/ep1.cfg diff --git a/examples/ipsec-secgw/ep0.cfg b/examples/ipsec-secgw/ep0.cfg new file mode 100644 index 000..c10e22b --- /dev/null +++ b/examples/ipsec-secgw/ep0.cfg @@ -0,0 +1,119 @@ +### +# IPSEC-SECGW Endpoint sample configuration +# +# The main purpose of this file is to show how to configure two systems +# back-to-back that would forward traffic through an IPsec tunnel. This +# file is the Endpoint 0 configuration. To use this configuration file, +# add the following command-line option: +# +# -f ./ep0.cfg +# +### + +#SP IPv4 rules +sp ipv4 out esp protect 5 pri 1 dst 192.168.105.0/24 sport 0:65535 dport 0:65535 +sp ipv4 out esp protect 6 pri 1 dst 192.168.106.0/24 sport 0:65535 dport 0:65535 +sp ipv4 out esp protect 10 pri 1 dst 192.168.175.0/24 sport 0:65535 dport 0:65535 +sp ipv4 out esp protect 11 pri 1 dst 192.168.176.0/24 sport 0:65535 dport 0:65535 +sp ipv4 out esp protect 15 pri 1 dst 192.168.200.0/24 sport 0:65535 dport 0:65535 +sp ipv4 out esp protect 16 pri 1 dst 192.168.201.0/24 sport 0:65535 dport 0:65535 +sp ipv4 out esp protect 25 pri 1 dst 192.168.55.0/24 sport 0:65535 dport 0:65535 +sp ipv4 out esp protect 26 pri 1 dst 192.168.56.0/24 sport 0:65535 dport 0:65535 +sp ipv4 out esp bypass pri 1 dst 192.168.240.0/24 sport 0:65535 dport 0:65535 +sp ipv4 out esp bypass pri 1 dst 192.168.241.0/24 sport 0:65535 dport 0:65535 + +sp ipv4 in esp protect 105 pri 1 dst 192.168.115.0/24 sport 0:65535 dport 0:65535 +sp ipv4 in esp protect 106 pri 1 dst 192.168.116.0/24 sport 0:65535 dport 0:65535 +sp ipv4 in esp protect 110 pri 1 dst 192.168.185.0/24 sport 0:65535 dport 0:65535 +sp ipv4 in esp protect 111 pri 1 dst 192.168.186.0/24 sport 0:65535 dport 0:65535 +sp ipv4 in esp protect 115 pri 1 dst 192.168.210.0/24 sport 0:65535 dport 0:65535 +sp ipv4 in esp protect 116 pri 1 dst 192.168.211.0/24 sport 0:65535 dport 0:65535 +sp ipv4 in esp protect 115 pri 1 dst 192.168.210.0/24 sport 0:65535 dport 0:65535 +sp ipv4 in esp protect 125 pri 1 dst 192.168.65.0/24 sport 0:65535 dport 0:65535 +sp ipv4 in esp protect 125 pri 1 dst 192.168.65.0/24 sport 0:65535 dport 0:65535 +sp ipv4 in esp protect 126 pri 1 dst 192.168.66.0/24 sport 0:65535 dport 0:65535 +sp ipv4 in esp bypass pri 1 dst 192.168.245.0/24 sport 0:65535 dport 0:65535 +sp ipv4 in esp bypass pri 1 dst 192.168.246.0/24 sport 0:65535 dport 0:65535 + +#SP IPv6 rules +sp ipv6 out esp protect 5 pri 1 dst :::::::/96 \ +sport 0:65535 dport 0:65535 +sp ipv6 out esp protect 6 pri 1 dst :::::::/96 \ +sport 0:65535 dport 0:65535 +sp ipv6 out esp protect 10 pri 1 dst :::::::/96 \ +sport 0:65535 dport 0:65535 +sp ipv6 out esp protect 11 pri 1 dst :::::::/96 \ +sport 0:65535 dport 0:65535 +sp ipv6 out esp protect 25 pri 1 dst :::::::/96 \ +sport 0:65535 dport 0:65535 +sp ipv6 out esp protect 26 pri 1 dst :::::::/96 \ +sport 0:65535 dport 0:65535 + +sp ipv6 in esp protect 15 pri 1 dst :::::::/96 \ +sport 0:65535 dport 0:65535 +sp ipv6 in esp protect 16 pri 1 dst :::::::/96 \ +sport 0:65535 dport 0:65535 +sp ipv6 in esp protect 110 pri 1 dst :::::::/96 \ +sport 0:65535 dport 0:65535 +sp ipv6 in esp protect 111 pri 1 dst :::::::/96 \ +sport 0:65535 dport 0:65535 +sp ipv6 in esp protect 125 pri 1 dst :::::::/96 \ +sport 0:65535 dport 0:65535 +sp ipv6 in esp protect 126 pri 1 dst :::::::/96 \ +sport 0:65535 dport 0:65535 + +#SA rules +sa out 5 aes-128-cbc sha1-hmac ipv4-tunnel src 172.16.1.5 dst 172.16.2.5 +sa out 6 aes-128-cbc sha1-hmac ipv4-tunnel src 172.16.1.6 dst 172.16.2.6 +sa out 10 aes-128-cbc sha1-hmac transport +sa out 11 aes-128-cbc sha1-hmac transport +sa out 15 null null ipv4-tunnel src 172.16.1.5 dst 172.16.2.5 +sa out 16 null null ipv4-tunnel src 172.16.1.6 dst 172.16.2.6 +sa out 25 aes-128-cbc sha1-hmac ipv6-tunnel \ +src ::::::: \ +dst ::::::: +sa out 26 aes-128-cbc sha1-hmac ipv6-tunnel \ +src :11
[dpdk-dev] [PATCH] examples/l2fwd-crypto: out-of-bounds read
> > Overrunning array crypto_statistics of 32 64-byte elements
> > at element index 63 using index cdevid.
> > Fixed by extend crypto_statistics array.
> >
> > Fixes: 387259bd6c67 ("examples/l2fwd-crypto: add sample application")
> > Coverity ID 120145
> >
> > Signed-off-by: Slawomir Mrozowicz
> >
> Acked-by: Declan Doherty
Applied, thanks
[dpdk-dev] [PATCH] examples/l2fwd-crypto: fix incorrect stats array length
2016-06-28 09:28, Declan Doherty:
> On 27/06/16 14:37, Pablo de Lara wrote:
> > crypto_statistics array was not big enough for storing
> > all the possible crypto device statistics, as its size was
> > RTE_MAX_ETHPORTS, but should be RTE_CRYPTO_MAX_DEVS, leading
> > this to a potential out-of-bounds issue.
> >
> > Coverity issue: 120145
> >
> > Fixes: 387259bd6c67 ("examples/l2fwd-crypto: add sample application")
> >
> > Signed-off-by: Pablo de Lara
>
> Acked-by: Declan Doherty
Slawomir sent the same fix, so kind of applied :)
[dpdk-dev] [PATCH 1/2] doc: live migration of VM with vhost_user on host
This patch describes the procedure to be be followed to perform Live Migration of a VM with Virtio PMD running on a host which is running the vhost_user sample application (vhost-switch). It includes sample host and VM scripts used in the procedure. Signed-off-by: Bernard Iremonger --- doc/guides/howto/index.rst| 1 + doc/guides/howto/lm_virtio_vhost_user.rst | 504 ++ 2 files changed, 505 insertions(+) create mode 100644 doc/guides/howto/lm_virtio_vhost_user.rst diff --git a/doc/guides/howto/index.rst b/doc/guides/howto/index.rst index 4b97a32..d3e3a90 100644 --- a/doc/guides/howto/index.rst +++ b/doc/guides/howto/index.rst @@ -36,3 +36,4 @@ How To User Guide :numbered: lm_bond_virtio_sriov +lm_virtio_vhost_user diff --git a/doc/guides/howto/lm_virtio_vhost_user.rst b/doc/guides/howto/lm_virtio_vhost_user.rst new file mode 100644 index 000..dbcd1d3 --- /dev/null +++ b/doc/guides/howto/lm_virtio_vhost_user.rst @@ -0,0 +1,504 @@ +.. BSD LICENSE +Copyright(c) 2016 Intel Corporation. All rights reserved. +All rights reserved. + +Redistribution and use in source and binary forms, with or without +modification, are permitted provided that the following conditions +are met: + +* Redistributions of source code must retain the above copyright +notice, this list of conditions and the following disclaimer. +* Redistributions in binary form must reproduce the above copyright +notice, this list of conditions and the following disclaimer in +the documentation and/or other materials provided with the +distribution. +* Neither the name of Intel Corporation nor the names of its +contributors may be used to endorse or promote products derived +from this software without specific prior written permission. + +THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS +"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT +LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR +A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT +OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, +SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT +LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, +DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY +THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT +(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE +OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + + +Live Migration of VM with Virtio on host running vhost_user: + + +Live Migration overview for VM with Virtio: +--- + +To test the Live Migration two servers with identical operating systems installed are used. +KVM and QEMU is also required on the servers. + +QEMU 2.5 is required for Live Migration of a VM with vhost_user running on the hosts. + +The servers have Niantic and or Fortville NIC's installed. +The NIC's on both servers are connected to a switch +which is also connected to the traffic generator. + +The switch is configured to broadcast traffic on all the NIC ports. + +Live Migration with Virtio and vhost_user test setup: +- + +Live Migration steps for VM with Virtio PMD and vhost_user on host: +--- + +The host is running the DPDK PMD (ixgbe or i40e) and the DPDK vhost_user +sample application (vhost-switch). + +The ip address of host_server_1 is 10.237.212.46 + +The ip address of host_server_2 is 10.237.212.131 + +The sample scripts mentioned in the steps below can be found in the host_scripts +and vm_scripts sections. + +On host_server_1: Terminal 1 + + +Setup DPDK on host_server_1 + +.. code-block:: console + +cd /root/dpdk/host_scripts +./setup_dpdk_on_host.sh + +On host_server_1: Terminal 2 + + +Bind the Niantic or Fortville NIC to igb_uio on host_server_1. + +For Fortville NIC + +.. code-block:: console + + cd /root/dpdk/tools + ./dpdk_nic_bind.py -b igb_uio :02:00.0 + +For Niantic NIC + +.. code-block:: console + + cd /root/dpdk/tools + ./dpdk_nic_bind.py -b igb_uio :09:00.0 + +On host_server_1: Terminal 3 + + +For Fortville and Niantic NIC's reset SRIOV and run the +vhost_user sample application (vhost-switch) on host_server_1. + +.. code-block:: console + + cd /root/dpdk/host_scripts +./reset_vf_on_212_46.sh +./run_vhost_switch_on_host.sh + +On host_server_1: Terminal 1 + + +Start the VM on host_server_1 + +.. code-block:: console + + ./vm_virtio_vhost_user.sh + +On host_server_1: Terminal 4 +^^
[dpdk-dev] [PATCH 0/2] doc: live migration procedure with vhost_user
This patchset describes the procedure to Live migrate a VM with Virtio PMD's with the vhost_user sample application (vhost-switch) running on the host. Bernard Iremonger (2): doc: live migration of VM with vhost_user on host doc: add vhost_user live migration image doc/guides/howto/img/lm_vhost_user.svg| 644 ++ doc/guides/howto/index.rst| 1 + doc/guides/howto/lm_virtio_vhost_user.rst | 508 +++ 3 files changed, 1153 insertions(+) create mode 100644 doc/guides/howto/img/lm_vhost_user.svg create mode 100644 doc/guides/howto/lm_virtio_vhost_user.rst -- 2.9.0
[dpdk-dev] [PATCH 2/2] doc: add vhost_user live migration image
This patch adds an image of the Live Migration of a VM using vhost_user on the host, test configuration. Signed-off-by: Bernard Iremonger --- doc/guides/howto/img/lm_vhost_user.svg| 644 ++ doc/guides/howto/lm_virtio_vhost_user.rst | 4 + 2 files changed, 648 insertions(+) create mode 100644 doc/guides/howto/img/lm_vhost_user.svg diff --git a/doc/guides/howto/img/lm_vhost_user.svg b/doc/guides/howto/img/lm_vhost_user.svg new file mode 100644 index 000..35cf4d0 --- /dev/null +++ b/doc/guides/howto/img/lm_vhost_user.svg @@ -0,0 +1,644 @@ + + + +http://purl.org/dc/elements/1.1/"; + xmlns:cc="http://creativecommons.org/ns#"; + xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"; + xmlns:svg="http://www.w3.org/2000/svg"; + xmlns="http://www.w3.org/2000/svg"; + xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"; + xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"; + width="1052.8693" + height="762.99158" + id="svg2" + version="1.1" + inkscape:version="0.48.4 r9939" + sodipodi:docname="lm_vhost_user.svg"> + + + + + + + + + + + + + + + + + + + + + + + + +image/svg+xml +http://purl.org/dc/dcmitype/StillImage"; /> + + + + + + + + + + + + + +VM 1 +Switch with 10Gb ports +Server 1 +Server 2 + 10 Gb Traffic Generator +VM 2 +Linux, KVM, QEMU 2.5 +10 Gb NIC +10 Gb NIC + + +10 Gb NIC +10 Gb NIC + + +DPDK Testpmd Appor L2fwd App. +DPDK virtio PMD devices +DPDK PF PMD +DPDK PF PMD +NFS ServerVM disk image + + + + + + + + + + + + + + + +10 Gb Migration Link +DPDK Testpmd Appor L2fwd App. +DPDK virtio PMD devices +Linux, KVM, QEMU 2.5 + + diff --git a/doc/guides/howto/lm_virtio_vhost_user.rst b/doc/guides/howto/lm_virtio_vhost_user.rst index dbcd1d3..c505772 100644 --- a/doc/guides/howto/lm_virtio_vhost_user.rst +++ b/doc/guides/howto/lm_virtio_vhost_user.rst @@ -49,6 +49,10 @@ The switch is configured to broadcast traffic on all the NIC ports. Live Migration with Virtio and vhost_user test setup: - +.. _figure_lm_vhost_user: + +.. figure:: img/lm_vhost_user.* + Live Migration steps for VM with Virtio PMD and vhost_user on host: --- -- 2.9.0
[dpdk-dev] [PATCH] examples/l2fwd-crypto: flush crypto dev buffers
2016-07-06 10:38, Pablo de Lara:
> Crypto operations are enqueued in the crypto devices
> when the crypto device buffers are full (MAX_PKT_BURST),
> in order to be more efficient.
>
> The problem is that operations might be stuck in those buffers,
> if they never get full, and therefore, those operations
> will never be performed.
>
> Therefore, it is necessary to have a buffer flush mechanism,
> similar to the one used for flush the TX buffers, so eventually,
> all packets received are ciphered and sent out.
>
> Fixes: 387259bd6c67 ("examples/l2fwd-crypto: add sample application")
>
> Signed-off-by: Pablo de Lara
Applied, thanks
[dpdk-dev] [PATCH v2 1/2] examples/ipsec-secgw: add configuration file support
2016-07-11 15:43, Fan Zhang:
> This patch adds the configuration file support to ipsec_secgw
> sample application. Instead of hard-coded rules, the users can
> specify their own SP, SA, and routing rules in the configuration
> file. An command line option "-f" is added to pass the
> configuration file location to the application.
There is a 32-bit compilation error:
examples/ipsec-secgw/parser.c:286:10: error:
format ?%lu? expects argument of type ?long unsigned int?,
but argument 2 has type ?size_t {aka unsigned int}? [-Werror=format=]
printf("len error, has %lu, expect %i\n", strlen(ip_str),
[dpdk-dev] [PATCH] examples/vm_power_manager: remove dependency on internal header file
2016-07-04 16:57, Marvin Liu: > Macro CHANNEL_CMDS_MAX_CPUS stand for the maximum number of cores > controlled by virtual channels. This macro only be used in the example, > so remove it from library to example header file. > > Signed-off-by: Marvin Liu Applied, thanks
[dpdk-dev] [PATCH v2] ip_pipeline: add Python script file for creating visual diagram of IP pipeline config file
> > This commit adds Python script for generating diagram of the application > > configuration file. This script requires graphviz package to be installed > > on the machine. The input config file is translated to an output file in > > DOT syntax, which is then used to create the image file using graphviz. > > > > To run the script, following command is used; > > > > ./diagram-generator.py -f > > > > Some optional arguments are as follows: > > -h, --helpshow this help message and exit > > > > Signed-off-by: Jasvinder Singh > > Signed-off-by: Cristian Dumitrescu > > Acked-by: Cristian Dumitrescu > > > The subject line is too long: > > $ scripts/check-git-log.sh > Headline too long: > ip_pipeline: add Python script file for creating visual diagram of IP > pipeline config file > > I would suggest something like: > > ip_pipeline: add script for creating config diagrams or examples/ip_pipeline: add config diagram generator > The code looks good though, so: > > Acked-by: John McNamara Applied, thanks This example become more and more complex...
[dpdk-dev] [PATCH v6 0/4] support reset of VF link
On Mon, 2016-07-11 at 13:02 +0100, Luca Boccassi wrote: > On Mon, 2016-07-11 at 01:32 +, Lu, Wenzhuo wrote: > > > > > > Unfortunately I found one issue: if PF is down, and then the VF on the > > > guest is > > > down as well (ip link down) and then goes back up before the PF, then > > > calling > > > rte_eth_dev_reset will return 0 (success), even though the PF is still > > > down and it > > > should fail. This is with ixgbe. Any idea what could be the problem? > > I've found this interesting thing. I believe it?s the HW difference between > > igb and ixgbe. When the link is down, ixgbe VF can be reset successfully > > but igb VF cannot. The expression is the registers of the ixgbe VF can be > > accessed when the PF link is down but igb VF cannot. > > It means, on ixgbe, when PF link is down, we reset the VF link. Then PF > > link is up, we receive the message again and reset the VF link again. > > What message do you refer to here? I am seeing the RESET callback only > when the PF goes down, not when it goes up. > > At the moment, with ixgbe, this happens: > > PF down -> reset notification, rte_eth_dev_reset keeps failing -> VF > down -> VF up -> rte_eth_dev_reset in a loop/timer succeeds -> PF up -> > VF link has no-carrier, and traffic does NOT go through > > The problem is that there is just no way of being notified that PF is > up, and if rte_eth_dev_reset succeeds I have no way of knowing that I > need to run it again. I was now able to solve this use case, by having the rte_eth_dev_reset implementations return -EAGAIN if the dev is not up. This way I know, in the application, that I have to try again. What do you think? IMHO it makes sense, as the reset does not actually succeeds, and the caller should try again. The diff is very trivial, and attached for reference. -- Kind regards, Luca Boccassi Make rte_eth_dev_reset return EAGAIN if VF down If VF is down the reset will not happen, so the driver should return EAGAIN to signal the application that it needs to call again rte_eth_dev_reset. Signed-off-by: Luca Boccassi data->dev_started) -return 0; +return -EAGAIN; PMD_DRV_LOG(DEBUG, "Link up/down event detected."); --- a/drivers/net/i40e/i40e_ethdev_vf.c +++ b/drivers/net/i40e/i40e_ethdev_vf.c @@ -1504,7 +1504,7 @@ i40evf_handle_vf_reset(struct rte_eth_de I40E_DEV_PRIVATE_TO_ADAPTER(dev->data->dev_private); if (!dev->data->dev_started) -return 0; +return -EAGAIN; adapter->reset_number = 1; i40e_vf_reset_dev(dev); --- a/drivers/net/e1000/igb_ethdev.c +++ b/drivers/net/e1000/igb_ethdev.c @@ -2609,7 +2609,7 @@ igbvf_dev_reset(struct rte_eth_dev *dev, /* Nothing needs to be done if the device is not started. */ if (!dev->data->dev_started) -return 0; +return -EAGAIN; PMD_DRV_LOG(DEBUG, "Link up/down event detected.");
[dpdk-dev] pktgen wr_cksum error
Hello I'm trying to build pktgen-v3.0.05 with dpdk 16.04 for with RTE_TARGET x86_64-native-linuxapp-gcc. Seemts that the build is failing due to an error on wr_cksum.c. Is something I can try to fix this error and build pktgen successfully? Not sure if others have had this error before. # make == lib == common CC wr_cksum.o In file included from /root/pktgen-v3.0.05/lib/common/wr_cksum.c:102:0: /root/pktgen-v3.0.05/lib/common/wr_mbuf.h: In function '__pktmbuf_alloc_noreset': /root/pktgen-v3.0.05/lib/common/wr_mbuf.h:47:2: error: 'for' loop initial declarations are only allowed in C99 mode /root/pktgen-v3.0.05/lib/common/wr_mbuf.h:47:2: note: use option -std=c99 or -std=gnu99 to compile your code make[3]: *** [wr_cksum.o] Error 1 make[2]: *** [all] Error 2 make[1]: *** [common] Error 2 make: *** [lib] Error 2 root at pktgen:~ EP
[dpdk-dev] [PATCH 0/4] fix mempool creation with Xen Dom0
On 07/11/2016 12:20 PM, Olivier Matz wrote: > Since the recent mempool rework [1], Xen Dom0 is broken. > This series aims at fixing it. I think it should be integrated > in 16.07. > > As I don't have a full testing platform, any help in validating > this patchset would be appreciated. > > [1] http://www.dpdk.org/ml/archives/dev/2016-May/039229.html I forgot to mention: Reported-by: Xu, HuilongX Thanks
[dpdk-dev] [PATCH v4 00/10] kill global pci device id list (almost)
2016-07-11 16:40, David Marchand: > With the introduction of pmdinfo by Neil, we have almost everything in place > to get rid of the pci devices in eal. > > We still have some ties with some pmds for functionalities like kni/ethtool or > ixgbe bypass api, so the plan has switched to touch all pmds but those igb and > ixgbe drivers. > > Since we still need rte_pci_dev_ids.h for those drivers, I just stripped the > doxygen parts to stop referencing it in the documentation. > > I have validated this patchset by comparing the pmdinfo outputs and just > noticed a difference for enic (where the pci ids were registered twice > before). > Yet, please maintainers review carefully. Applied, thanks
[dpdk-dev] [PATCH] i40e: move PCI device ids to driver
2016-07-11 12:01, Jingjing Wu: > move PCI device ids from rte_pci_dev_ids.h to driver. > > Signed-off-by: Jingjing Wu Thanks David has sent a v4 for almost every drivers, including i40e: http://dpdk.org/ml/archives/dev/2016-July/043798.html
[dpdk-dev] [PATCH 0/4] fix mempool creation with Xen Dom0
2016-07-11 12:20, Olivier Matz:
> Since the recent mempool rework [1], Xen Dom0 is broken.
> This series aims at fixing it. I think it should be integrated
> in 16.07.
>
> As I don't have a full testing platform, any help in validating
> this patchset would be appreciated.
>
> [1] http://www.dpdk.org/ml/archives/dev/2016-May/039229.html
>
> Olivier Matz (4):
> eal: fix typo in Xen Dom0 specific code
> mbuf: set errno on pool creation error
> eal: fix retrieval of phys address with Xen Dom0
> mempool: fix creation with Xen Dom0
Applied with an additional fix:
xen: fix build as shared library
When building as shared library, the compiler complains for
undefined reference to `rte_xen_mem_phy2mch'
The symbol rte_xen_mem_phy2mch was introduced in DPDK 2.2
and has been called in mempool recently via rte_mem_phy2mch.
Fixes: c042ba20674a ("mempool: rework support of Xen dom0")
