[dpdk-dev] [PATCH v4 08/14] virtio: pci: extend virtio pci rw api for vfio interface
On Fri, Jan 15, 2016 at 07:12:04PM +0530, Santosh Shukla wrote:
> On Fri, Jan 15, 2016 at 6:13 PM, Santosh Shukla wrote:
> > On Fri, Jan 15, 2016 at 11:57 AM, Yuanhan Liu
> > wrote:
> >> On Thu, Jan 14, 2016 at 06:58:31PM +0530, Santosh Shukla wrote:
> >>> So far virtio handle rw access for uio / ioport interface, This patch to
> >>> extend
> >>> the support for vfio interface. For that introducing private struct
> >>> virtio_vfio_dev{
> >>> - is_vfio
> >>> - pci_dev
> >>> };
> >>> Signed-off-by: Santosh Shukla
> >> ...
> >>> +/* For vfio only */
> >>> +struct virtio_vfio_dev {
> >>> + boolis_vfio;/* True: vfio i/f,
> >>> + * False: not a vfio i/f
> >>
> >> Well, this is weird; you are adding a flag to tell whether it's a
> >> vfio device __inside__ a vfio struct.
> >>
> >> Back to the topic, this flag is not necessary to me: you can
> >> check the pci_dev->kdrv flag.
> >>
> >
> > yes, I'll replace is_vfio with pci_dev->kdrv.
> >
> >>> + */
> >>> + struct rte_pci_device *pci_dev; /* vfio dev */
> >>
> >> Note that I have already added this field into virtio_hw struct
> >> at my latest virtio 1.0 pmd patchset.
> >>
> >> While I told you before that you should not develop patches based
> >> on my patcheset, I guess you can do that now. Since it should be
> >> in good shape and close to be merged.
> >
> > Okay, Before rebasing my v5 patch on your 1.0 virtio patch, I like to
> > understand which qemu version support virtio 1.0 spec?
>
> Ignore, I figured out in other thread,
> qemu version >2.4, such as 2.4.1 or 2.5.0.
It will not matter. You can continue using the old legacy virtio, which
is the default case: my patchset keeps the backward compatibility.
What's worty noting is that virtio 1.0 uses memory mmaped bar space for
configuration, instead of ioport reading/writing. Therefore, I'd suggest
you to keep testing with legacy virtio, to make sure the VFIO stuff works.
And off course, virtio 1.0 testing is also welcome, to make sure it works
on ARM as well.
--yliu
[dpdk-dev] [PATCH v4 08/14] virtio: pci: extend virtio pci rw api for vfio interface
On Mon, Jan 18, 2016 at 11:41 AM, Yuanhan Liu
wrote:
> On Fri, Jan 15, 2016 at 07:12:04PM +0530, Santosh Shukla wrote:
>> On Fri, Jan 15, 2016 at 6:13 PM, Santosh Shukla
>> wrote:
>> > On Fri, Jan 15, 2016 at 11:57 AM, Yuanhan Liu
>> > wrote:
>> >> On Thu, Jan 14, 2016 at 06:58:31PM +0530, Santosh Shukla wrote:
>> >>> So far virtio handle rw access for uio / ioport interface, This patch to
>> >>> extend
>> >>> the support for vfio interface. For that introducing private struct
>> >>> virtio_vfio_dev{
>> >>> - is_vfio
>> >>> - pci_dev
>> >>> };
>> >>> Signed-off-by: Santosh Shukla
>> >> ...
>> >>> +/* For vfio only */
>> >>> +struct virtio_vfio_dev {
>> >>> + boolis_vfio;/* True: vfio i/f,
>> >>> + * False: not a vfio i/f
>> >>
>> >> Well, this is weird; you are adding a flag to tell whether it's a
>> >> vfio device __inside__ a vfio struct.
>> >>
>> >> Back to the topic, this flag is not necessary to me: you can
>> >> check the pci_dev->kdrv flag.
>> >>
>> >
>> > yes, I'll replace is_vfio with pci_dev->kdrv.
>> >
>> >>> + */
>> >>> + struct rte_pci_device *pci_dev; /* vfio dev */
>> >>
>> >> Note that I have already added this field into virtio_hw struct
>> >> at my latest virtio 1.0 pmd patchset.
>> >>
>> >> While I told you before that you should not develop patches based
>> >> on my patcheset, I guess you can do that now. Since it should be
>> >> in good shape and close to be merged.
>> >
>> > Okay, Before rebasing my v5 patch on your 1.0 virtio patch, I like to
>> > understand which qemu version support virtio 1.0 spec?
>>
>> Ignore, I figured out in other thread,
>> qemu version >2.4, such as 2.4.1 or 2.5.0.
>
> It will not matter. You can continue using the old legacy virtio, which
> is the default case: my patchset keeps the backward compatibility.
>
> What's worty noting is that virtio 1.0 uses memory mmaped bar space for
> configuration, instead of ioport reading/writing. Therefore, I'd suggest
> you to keep testing with legacy virtio, to make sure the VFIO stuff works.
> And off course, virtio 1.0 testing is also welcome, to make sure it works
> on ARM as well.
>
I am testing for virtio 1.0 and 0.95 for arm including your patch,
soon we;ll post the patch series that is rebased on / dependent on
below patchset:
- virtio 1.0
- vfio-noiommu
- KDRV check by huawei
IMO, we should start merging the dependent patches as because I'll
have to rebase, then do regression across the platform at least for
x86/arm64 and it's quite a work now.
Beside that I have few question specific to vfio in virtio pmd driver;
- vfio don't need resource_init functionality as it uses struct
rte_pci_dev but it need parsing so to make sure
1. user has setted no_iommu mode
2. virtio pci device attached to vfio-no-iommu driver or not.
So for 1) I am thinking to add RTE_KDRV_VFIO_NOIOMMU mode and a helper
function like pci_vfio_is_iommu(), such that pc_xxx_scan() function
updates dev->kdrv with RTE_KDRV_VFIO_NOIOMMU at driver probe time.
case 2) would check for _noiommu mode and then would verify that
driver is attached or not?
above two case applicable to both virtio spec 1.0 and 0.95. I have
done changes for those two case for v5 patch series,l any comment
welcome before I push patch for review.
Thanks.
> --yliu
[dpdk-dev] [PATCH v4 08/14] virtio: pci: extend virtio pci rw api for vfio interface
On 01/14/2016 09:28 PM, Santosh Shukla wrote:
> So far virtio handle rw access for uio / ioport interface, This patch to
> extend
> the support for vfio interface. For that introducing private struct
> virtio_vfio_dev{
> - is_vfio
> - pci_dev
> };
> Signed-off-by: Santosh Shukla
> ---
> v3->v4:
> - Removed #indef RTE_EAL_VFIO and made it arch agnostic such now virtio_pci
> rd/wr api to handle both vfio and ig_uio/ioport interfaces, depending upon
> is_vfio flags set or unset.
> - Tested for x86 for igb_uio and vfio interface, also tested for arm64 for
> vfio
> interface.
>
> drivers/net/virtio/virtio_pci.h | 84 ---
> 1 file changed, 70 insertions(+), 14 deletions(-)
Interesting. I'm working on IOMMU cooperation with virtio[1]. For pmd,
it looks like the only thing missed is RTE_PCI_DRV_NEED_MAPPING for
virito-net pmd.
So I'm curious whether this is still necessary if IOMMU can work with
virito in the future.
[1] https://www.mail-archive.com/qemu-devel at nongnu.org/msg337079.html
Thanks
>
> diff --git a/drivers/net/virtio/virtio_pci.h b/drivers/net/virtio/virtio_pci.h
> index 8b5b031..8526c07 100644
> --- a/drivers/net/virtio/virtio_pci.h
> +++ b/drivers/net/virtio/virtio_pci.h
> @@ -46,6 +46,8 @@
> #endif
>
> #include
> +#include
> +#include "virtio_vfio_rw.h"
>
> struct virtqueue;
>
> @@ -165,6 +167,14 @@ struct virtqueue;
> */
> #define VIRTIO_MAX_VIRTQUEUES 8
>
> +/* For vfio only */
> +struct virtio_vfio_dev {
> + boolis_vfio;/* True: vfio i/f,
> + * False: not a vfio i/f
> + */
> + struct rte_pci_device *pci_dev; /* vfio dev */
> +};
> +
> struct virtio_hw {
> struct virtqueue *cvq;
> uint32_tio_base;
> @@ -176,6 +186,7 @@ struct virtio_hw {
> uint8_t use_msix;
> uint8_t started;
> uint8_t mac_addr[ETHER_ADDR_LEN];
> + struct virtio_vfio_dev dev;
> };
>
> /*
> @@ -231,20 +242,65 @@ outl_p(unsigned int data, unsigned int port)
> #define VIRTIO_PCI_REG_ADDR(hw, reg) \
> (unsigned short)((hw)->io_base + (reg))
>
> -#define VIRTIO_READ_REG_1(hw, reg) \
> - inb((VIRTIO_PCI_REG_ADDR((hw), (reg
> -#define VIRTIO_WRITE_REG_1(hw, reg, value) \
> - outb_p((unsigned char)(value), (VIRTIO_PCI_REG_ADDR((hw), (reg
> -
> -#define VIRTIO_READ_REG_2(hw, reg) \
> - inw((VIRTIO_PCI_REG_ADDR((hw), (reg
> -#define VIRTIO_WRITE_REG_2(hw, reg, value) \
> - outw_p((unsigned short)(value), (VIRTIO_PCI_REG_ADDR((hw), (reg
> -
> -#define VIRTIO_READ_REG_4(hw, reg) \
> - inl((VIRTIO_PCI_REG_ADDR((hw), (reg
> -#define VIRTIO_WRITE_REG_4(hw, reg, value) \
> - outl_p((unsigned int)(value), (VIRTIO_PCI_REG_ADDR((hw), (reg
> +#define VIRTIO_READ_REG_1(hw, reg) \
> +({ \
> + uint8_t ret;\
> + struct virtio_vfio_dev *vdev; \
> + (vdev) = (&(hw)->dev); \
> + (((vdev)->is_vfio) ?\
> + (ioport_inb(((vdev)->pci_dev), reg, &ret)) :\
> + ((ret) = (inb((VIRTIO_PCI_REG_ADDR((hw), (reg))); \
> + ret;\
> +})
> +
> +#define VIRTIO_WRITE_REG_1(hw, reg, value) \
> +({ \
> + struct virtio_vfio_dev *vdev; \
> + (vdev) = (&(hw)->dev); \
> + (((vdev)->is_vfio) ?\
> + (ioport_outb_p(((vdev)->pci_dev), reg, (uint8_t)(value))) : \
> + (outb_p((unsigned char)(value), (VIRTIO_PCI_REG_ADDR((hw), (reg)); \
> +})
> +
> +#define VIRTIO_READ_REG_2(hw, reg) \
> +({ \
> + uint16_t ret; \
> + struct virtio_vfio_dev *vdev; \
> + (vdev) = (&(hw)->dev); \
> + (((vdev)->is_vfio) ?\
> + (ioport_inw(((vdev)->pci_dev), reg, &ret)) :\
> + ((ret) = (inw((VIRTIO_PCI_REG_ADDR((hw), (reg))); \
> + ret;\
> +})
> +
> +#define VIRTIO_WRITE_REG_2(hw, reg, value) \
> +({ \
> + struct virtio_vfio_dev *vdev; \
> + (vdev) = (&(hw)->dev);
[dpdk-dev] [PATCH v4 08/14] virtio: pci: extend virtio pci rw api for vfio interface
On Mon, Jan 18, 2016 at 12:15:40PM +0530, Santosh Shukla wrote: > I am testing for virtio 1.0 and 0.95 for arm including your patch, > soon we;ll post the patch series that is rebased on / dependent on > below patchset: > - virtio 1.0 > - vfio-noiommu > - KDRV check by huawei > > IMO, we should start merging the dependent patches as because I'll Yep, agreed. That's why I was keep pushing Huawei for ACK and validation team for testing, although I have tested that. :) > have to rebase, then do regression across the platform at least for > x86/arm64 and it's quite a work now. > > Beside that I have few question specific to vfio in virtio pmd driver; > - vfio don't need resource_init functionality as it uses struct > rte_pci_dev but it need parsing so to make sure > 1. user has setted no_iommu mode > 2. virtio pci device attached to vfio-no-iommu driver or not. > > So for 1) I am thinking to add RTE_KDRV_VFIO_NOIOMMU mode and a helper > function like pci_vfio_is_iommu(), such that pc_xxx_scan() function > updates dev->kdrv with RTE_KDRV_VFIO_NOIOMMU at driver probe time. That sounds better to me. And that's also what I want to comment on your another patch [09/14], that we should try to avoid getting UIO/VFIO stuff inside virtio pmd driver, unless it's a must. (yes, I know UIO is already an example here, but I don't like it, and badly, I don't have the time to check if I can remove it.) > > case 2) would check for _noiommu mode and then would verify that > driver is attached or not? Sorry, very limited VFIO and noiommu knowledge, and I can't answer, so far. --yliu > > above two case applicable to both virtio spec 1.0 and 0.95. I have > done changes for those two case for v5 patch series,l any comment > welcome before I push patch for review. > > Thanks.
[dpdk-dev] [PATCH v4 08/14] virtio: pci: extend virtio pci rw api for vfio interface
On Mon, Jan 18, 2016 at 12:29 PM, Jason Wang wrote:
>
>
> On 01/14/2016 09:28 PM, Santosh Shukla wrote:
>> So far virtio handle rw access for uio / ioport interface, This patch to
>> extend
>> the support for vfio interface. For that introducing private struct
>> virtio_vfio_dev{
>> - is_vfio
>> - pci_dev
>> };
>> Signed-off-by: Santosh Shukla
>> ---
>> v3->v4:
>> - Removed #indef RTE_EAL_VFIO and made it arch agnostic such now virtio_pci
>> rd/wr api to handle both vfio and ig_uio/ioport interfaces, depending upon
>> is_vfio flags set or unset.
>> - Tested for x86 for igb_uio and vfio interface, also tested for arm64 for
>> vfio
>> interface.
>>
>> drivers/net/virtio/virtio_pci.h | 84
>> ---
>> 1 file changed, 70 insertions(+), 14 deletions(-)
>
> Interesting. I'm working on IOMMU cooperation with virtio[1]. For pmd,
> it looks like the only thing missed is RTE_PCI_DRV_NEED_MAPPING for
> virito-net pmd.
>
not missing anymore, I am using rte_eal_pci_map() api so to map virtio
pci dev to userspace.
> So I'm curious whether this is still necessary if IOMMU can work with
> virito in the future.
>
So far I'm using pmd driver in vfio-noiommu way. AFAIk, pmd driver use
dma for tx side. I glanced through your patch, to me it would be
interesting to try out, but right now I am not sure. We'll come back I
guess. Thanks
> [1] https://www.mail-archive.com/qemu-devel at nongnu.org/msg337079.html
>
> Thanks
>
>>
>> diff --git a/drivers/net/virtio/virtio_pci.h
>> b/drivers/net/virtio/virtio_pci.h
>> index 8b5b031..8526c07 100644
>> --- a/drivers/net/virtio/virtio_pci.h
>> +++ b/drivers/net/virtio/virtio_pci.h
>> @@ -46,6 +46,8 @@
>> #endif
>>
>> #include
>> +#include
>> +#include "virtio_vfio_rw.h"
>>
>> struct virtqueue;
>>
>> @@ -165,6 +167,14 @@ struct virtqueue;
>> */
>> #define VIRTIO_MAX_VIRTQUEUES 8
>>
>> +/* For vfio only */
>> +struct virtio_vfio_dev {
>> + boolis_vfio;/* True: vfio i/f,
>> + * False: not a vfio i/f
>> + */
>> + struct rte_pci_device *pci_dev; /* vfio dev */
>> +};
>> +
>> struct virtio_hw {
>> struct virtqueue *cvq;
>> uint32_tio_base;
>> @@ -176,6 +186,7 @@ struct virtio_hw {
>> uint8_t use_msix;
>> uint8_t started;
>> uint8_t mac_addr[ETHER_ADDR_LEN];
>> + struct virtio_vfio_dev dev;
>> };
>>
>> /*
>> @@ -231,20 +242,65 @@ outl_p(unsigned int data, unsigned int port)
>> #define VIRTIO_PCI_REG_ADDR(hw, reg) \
>> (unsigned short)((hw)->io_base + (reg))
>>
>> -#define VIRTIO_READ_REG_1(hw, reg) \
>> - inb((VIRTIO_PCI_REG_ADDR((hw), (reg
>> -#define VIRTIO_WRITE_REG_1(hw, reg, value) \
>> - outb_p((unsigned char)(value), (VIRTIO_PCI_REG_ADDR((hw), (reg
>> -
>> -#define VIRTIO_READ_REG_2(hw, reg) \
>> - inw((VIRTIO_PCI_REG_ADDR((hw), (reg
>> -#define VIRTIO_WRITE_REG_2(hw, reg, value) \
>> - outw_p((unsigned short)(value), (VIRTIO_PCI_REG_ADDR((hw), (reg
>> -
>> -#define VIRTIO_READ_REG_4(hw, reg) \
>> - inl((VIRTIO_PCI_REG_ADDR((hw), (reg
>> -#define VIRTIO_WRITE_REG_4(hw, reg, value) \
>> - outl_p((unsigned int)(value), (VIRTIO_PCI_REG_ADDR((hw), (reg
>> +#define VIRTIO_READ_REG_1(hw, reg) \
>> +({ \
>> + uint8_t ret;\
>> + struct virtio_vfio_dev *vdev; \
>> + (vdev) = (&(hw)->dev); \
>> + (((vdev)->is_vfio) ?\
>> + (ioport_inb(((vdev)->pci_dev), reg, &ret)) :\
>> + ((ret) = (inb((VIRTIO_PCI_REG_ADDR((hw), (reg))); \
>> + ret;\
>> +})
>> +
>> +#define VIRTIO_WRITE_REG_1(hw, reg, value) \
>> +({ \
>> + struct virtio_vfio_dev *vdev; \
>> + (vdev) = (&(hw)->dev); \
>> + (((vdev)->is_vfio) ?\
>> + (ioport_outb_p(((vdev)->pci_dev), reg, (uint8_t)(value))) : \
>> + (outb_p((unsigned char)(value), (VIRTIO_PCI_REG_ADDR((hw), (reg));
>> \
>> +})
>> +
>> +#define VIRTIO_READ_REG_2(hw, reg) \
>> +({ \
>> + uint16_t ret; \
>> + struct virtio_vfio_dev *vdev; \
>> + (vdev) = (&(hw)->dev); \
>> + (((vdev)->is_vfio) ?\
>> +
[dpdk-dev] [PATCH v2 1/1] vhost: fix leak of fds and mmaps
On Sun, Jan 17, 2016 at 11:57:18AM -0800, Rich Lane wrote:
> The common vhost code only supported a single mmap per device. vhost-user
> worked around this by saving the address/length/fd of each mmap after the end
> of the rte_virtio_memory struct. This only works if the vhost-user code frees
> dev->mem, since the common code is unaware of the extra info. The
> VHOST_USER_RESET_OWNER message is one situation where the common code frees
> dev->mem and leaks the fds and mappings. This happens every time I shut down a
> VM.
>
> The new code calls back into the implementation (vhost-user or vhost-cuse) to
> clean up these resources.
>
> The vhost-cuse changes are only compile tested.
>
> Signed-off-by: Rich Lane
> ---
> v1->v2:
> - Call into vhost-user/vhost-cuse to free mmaps.
>
> lib/librte_vhost/vhost-net.h | 6 ++
> lib/librte_vhost/vhost_cuse/virtio-net-cdev.c | 12
> lib/librte_vhost/vhost_user/vhost-net-user.c | 1 -
> lib/librte_vhost/vhost_user/virtio-net-user.c | 25 ++---
> lib/librte_vhost/vhost_user/virtio-net-user.h | 1 -
> lib/librte_vhost/virtio-net.c | 8 +---
> 6 files changed, 29 insertions(+), 24 deletions(-)
>
> diff --git a/lib/librte_vhost/vhost-net.h b/lib/librte_vhost/vhost-net.h
> index c69b60b..e8d7477 100644
> --- a/lib/librte_vhost/vhost-net.h
> +++ b/lib/librte_vhost/vhost-net.h
> @@ -115,4 +115,10 @@ struct vhost_net_device_ops {
>
>
> struct vhost_net_device_ops const *get_virtio_net_callbacks(void);
> +
> +/*
> + * Implementation-specific cleanup. Defined by vhost-cuse and vhost-user.
> + */
> +void vhost_impl_cleanup(struct virtio_net *dev);
TBH, I am not quite like "_impl_"; maybe "_backend_" is better?
OTOH, what I thought of has slight difference than yours: not
necessary to export a function, but instead, call the vhost
backend specific unmap function inside the backend itself. Say,
call vhost_user_unmap() on RESET_OWNER and connection close.
What do you think of that?
--yliu
[dpdk-dev] [PATCH v4 0/8] virtio 1.0 enabling for virtio pmd driver
On 2016/01/15 13:36, Yuanhan Liu wrote: > v4: - mark "src" arg as const for write_dev_cfg operation > > - remove unnessary inline, and likely/unlikely > > v3: - export pci_unmap_device as well; and invoke it at virtio > uninit stage. > > - fixed same data corruption bug reported by Qian in simple > rxtx code path. > > - move VIRTIO_READ/WRITE_REG_X to virtio_pci.c > > v2: - fix a data corruption reported by Qian, due to hdr size mismatch. > check detailes at ptach 5. > > - Add missing config_irq and isr reading support from v1. > > - fix comments from v1. > > Almost all difference comes from virtio 1.0 are the PCI layout change: > the major configuration structures are stored at bar space, and their > location is stored at corresponding pci cap structure. Reading/parsing > them is one of the major work of patch 7. > > To make handling virtio v1.0 and v0.95 co-exist well, this patch set > introduces a virtio_pci_ops structure, to add another layer so that > we could keep those vtpci_foo_bar "APIs". With that, we could do the > minimum change to add virtio 1.0 support. > > > Rough test guide > > > Firstly, you need get a virtio 1.0 supported QEMU (say, v2.5), then add > option "disable-modern=false" to qemu virtio-net-pci device to enable > virtio 1.0 (which is disabled by default). > > And if you see something like following from 'lspci -v', it means virtio > 1.0 is indeed enabled: > > 00:04.0 Ethernet controller: Red Hat, Inc Virtio network device > Subsystem: Red Hat, Inc Device 0001 > Physical Slot: 4 > Flags: bus master, fast devsel, latency 0, IRQ 11 > I/O ports at c040 [size=64] > Memory at febf1000 (32-bit, non-prefetchable) [size=4K] > Memory at fe00 (64-bit, prefetchable) [size=8M] > Expansion ROM at feb8 [disabled] [size=256K] > Capabilities: [98] MSI-X: Enable+ Count=6 Masked- > ==> Capabilities: [84] Vendor Specific Information: Len=14 > ==> Capabilities: [70] Vendor Specific Information: Len=14 > ==> Capabilities: [60] Vendor Specific Information: Len=10 > ==> Capabilities: [50] Vendor Specific Information: Len=10 > ==> Capabilities: [40] Vendor Specific Information: Len=10 > Kernel driver in use: virtio-pci > Kernel modules: virtio_pci > > After that, there wasn't anything speical comparing to the old virtio > 0.95 pmd driver. > > > --- > Yuanhan Liu (8): > virtio: don't set vring address again at queue startup > virtio: introduce struct virtio_pci_ops > virtio: move left pci stuff to virtio_pci.c > viritio: switch to 64 bit features > virtio: retrieve hdr_size from hw->vtnet_hdr_size > eal: pci: export pci_[un]map_device > virtio: add 1.0 support > virtio: move VIRTIO_READ/WRITE_REG_X into virtio_pci.c > > doc/guides/rel_notes/release_2_3.rst| 3 + > drivers/net/virtio/virtio_ethdev.c | 302 + > drivers/net/virtio/virtio_ethdev.h | 3 +- > drivers/net/virtio/virtio_pci.c | 793 > +++- > drivers/net/virtio/virtio_pci.h | 120 +++- > drivers/net/virtio/virtio_rxtx.c| 21 +- > drivers/net/virtio/virtio_rxtx_simple.c | 12 +- > drivers/net/virtio/virtqueue.h | 4 +- > lib/librte_eal/bsdapp/eal/eal_pci.c | 4 +- > lib/librte_eal/bsdapp/eal/rte_eal_version.map | 7 + > lib/librte_eal/common/eal_common_pci.c | 4 +- > lib/librte_eal/common/eal_private.h | 18 - > lib/librte_eal/common/include/rte_pci.h | 27 + > lib/librte_eal/linuxapp/eal/eal_pci.c | 4 +- > lib/librte_eal/linuxapp/eal/rte_eal_version.map | 7 + > 15 files changed, 949 insertions(+), 380 deletions(-) > Reviewed-by: Tetsuya Mukawa Tested-by: Tetsuya Mukawa
[dpdk-dev] [PATCH v2 0/7] virtio 1.0 enabling for virtio pmd driver
On 2016/01/14 15:41, Tetsuya Mukawa wrote:
>
>>> 2. Abstraction of read/write accesses.
>>>
>>> It may be difficult to cleanly rebase my patches on this patches,
>>> because virtio_read_caps() is not abstracted.
>>> Let me describe it more.
>>> So far, we need to handle below 3 virtio-net devices..
>>> - physical virtio-net device.
>>> - virtual virtio-net device in virtio-net PMD. (Jianfeng's patch)
>>> - virtual virtio-net device in QEMU. (my patch)
>>>
>>> Almost all code of the virtio-net PMD can be shared between above
>>> different cases.
>>> Probably big difference is how to access to configuration space.
>>>
>>> Yuanhan's patch introduces an abstraction layer to hide configuration
>>> space layout and how to access it.
>>> Is it possible to separate?
>>> I guess "access method" will be nice to be abstracted separately from
>>> "configuration space layout".
>>> Probably access method will be defined by "eth_dev->dev_type" and the
>>> PMD name like "eth_cvio".
>>> And "configuration space layout" will be defined by capability list of
>>> PCI configuration layout.
>>>
>>> For example, if access method like below are abstracted separately and
>>> current "virtio_pci.c" is implemented on this abstraction, we can easily
>>> re-use virtio_read_caps().
>>> - how to read/write virtio configuration space.
>>> - how to mmap PCI configuration space.
>>> - how to read/(write) PCI configuration space.
>>
>> I basically agree with you. We have two dimensions here:
>>
>> legacy modern
>> physical virtio device: Use
>> virtio_read_caps_phys() to distinguish
>> virtual virtio device (Tetsuya): Use virtio_read_caps_virt() to
>> distinguish
>> virtual virtio device (Jianfeng):does not need a "configuration
>> space layout", no need to distinguish
>>
>> So in vtpci_init(), we needs to test "eth_dev->dev_type" firstly
>>
>> vtpci_init() {
>> if (eth_dev->dev_type == RTE_ETH_DEV_PCI) {
>> if (virtio_read_caps_phys()) {
>> // modern
>> } else {
>> // legacy
>> }
>> } else {
>> if (Tetsuya's way) {
>> if (virtio_read_caps_virt()) {
>> // modern
>> } else {
>> // legacy
>> }
>> } else {
>> // Jianfeng's way
>> }
>> }
>> }
>>
>> And from Yuanhan's angle, I think he does not need to address this
>> problem. How do you think?
> Yes, I agree he doesn't need.
>
> Firstly, I have implemented like above, then I noticed that
> virtio_read_caps_phy() and virtio_read_caps_virt() are same except for
> access method.
> Anyway, I guess abstracting access method is not so difficult.
> If you are OK, I want to send RFC on Yuanhan's patch. Is it OK?
Hi Jianfeng,
I will submit patches to abstract pci access method.
The patches will be on Yuanhan's latest virtio-1.0 patches.
I guess your container patches also can be on the patches.
Could you please check it?
Thanks,
Tetsuya
[dpdk-dev] [PATCH 0/3] virtio: Add a new layer to abstract pci access method
The patches abstract pci access method of virtio-net PMD. The patch should be on Yuanhan's below patch series. - [PATCH v4 0/8] virtio 1.0 enabling for virtio pmd driver Tetsuya Mukawa (3): virtio: Change the parameter order of io_write8/16/32() virtio: move rte_eal_pci_unmap_device() to virtio_pci.c virtio: Add a new layer to abstract pci access method drivers/net/virtio/virtio_ethdev.c | 4 +- drivers/net/virtio/virtio_pci.c| 468 ++--- drivers/net/virtio/virtio_pci.h| 33 ++- 3 files changed, 369 insertions(+), 136 deletions(-) -- 2.1.4
[dpdk-dev] [PATCH 1/3] virtio: Change the parameter order of io_write8/16/32()
The patch change the parameter order of below functions.
- io_write8()
- io_write16()
- io_write32()
This changig are needed to add a new layer to abstract accessing
method.
Signed-off-by: Tetsuya Mukawa
---
drivers/net/virtio/virtio_pci.c | 66 -
1 file changed, 33 insertions(+), 33 deletions(-)
diff --git a/drivers/net/virtio/virtio_pci.c b/drivers/net/virtio/virtio_pci.c
index a9f179f..f1a6ee9 100644
--- a/drivers/net/virtio/virtio_pci.c
+++ b/drivers/net/virtio/virtio_pci.c
@@ -478,7 +478,7 @@ io_read##nr_bits(type *addr)\
#define MODERN_WRITE_DEF(nr_bits, type)\
static inline void \
-io_write##nr_bits(type val, type *addr)\
+io_write##nr_bits(type *addr, type val)\
{ \
*(volatile type *)addr = val; \
}
@@ -493,10 +493,10 @@ MODERN_READ_DEF (32, uint32_t)
MODERN_WRITE_DEF(32, uint32_t)
static inline void
-io_write64_twopart(uint64_t val, uint32_t *lo, uint32_t *hi)
+io_write64_twopart(uint32_t *lo, uint32_t *hi, uint64_t val)
{
- io_write32((uint32_t)val, lo);
- io_write32(val >> 32, hi);
+ io_write32(lo, (uint32_t)val);
+ io_write32(hi, val >> 32);
}
static void
@@ -526,7 +526,7 @@ modern_write_dev_config(struct virtio_hw *hw, uint64_t
offset,
const uint8_t *p = src;
for (i = 0; i < length; i++)
- io_write8(*p++, (uint8_t *)hw->dev_cfg + offset + i);
+ io_write8((uint8_t *)hw->dev_cfg + offset + i, *p++);
}
static uint64_t
@@ -534,10 +534,10 @@ modern_get_features(struct virtio_hw *hw)
{
uint32_t features_lo, features_hi;
- io_write32(0, &hw->common_cfg->device_feature_select);
+ io_write32(&hw->common_cfg->device_feature_select, 0);
features_lo = io_read32(&hw->common_cfg->device_feature);
- io_write32(1, &hw->common_cfg->device_feature_select);
+ io_write32(&hw->common_cfg->device_feature_select, 1);
features_hi = io_read32(&hw->common_cfg->device_feature);
return ((uint64_t)(features_hi) << 32) | features_lo;
@@ -546,13 +546,13 @@ modern_get_features(struct virtio_hw *hw)
static void
modern_set_features(struct virtio_hw *hw, uint64_t features)
{
- io_write32(0, &hw->common_cfg->guest_feature_select);
- io_write32(features & ((1ULL << 32) - 1),
- &hw->common_cfg->guest_feature);
+ io_write32(&hw->common_cfg->guest_feature_select, 0);
+ io_write32(&hw->common_cfg->guest_feature,
+ features & ((1ULL << 32) - 1));
- io_write32(1, &hw->common_cfg->guest_feature_select);
- io_write32(features >> 32,
- &hw->common_cfg->guest_feature);
+ io_write32(&hw->common_cfg->guest_feature_select, 1);
+ io_write32(&hw->common_cfg->guest_feature,
+ features >> 32);
}
static uint8_t
@@ -564,7 +564,7 @@ modern_get_status(struct virtio_hw *hw)
static void
modern_set_status(struct virtio_hw *hw, uint8_t status)
{
- io_write8(status, &hw->common_cfg->device_status);
+ io_write8(&hw->common_cfg->device_status, status);
}
static void
@@ -583,14 +583,14 @@ modern_get_isr(struct virtio_hw *hw)
static uint16_t
modern_set_config_irq(struct virtio_hw *hw, uint16_t vec)
{
- io_write16(vec, &hw->common_cfg->msix_config);
+ io_write16(&hw->common_cfg->msix_config, vec);
return io_read16(&hw->common_cfg->msix_config);
}
static uint16_t
modern_get_queue_num(struct virtio_hw *hw, uint16_t queue_id)
{
- io_write16(queue_id, &hw->common_cfg->queue_select);
+ io_write16(&hw->common_cfg->queue_select, queue_id);
return io_read16(&hw->common_cfg->queue_size);
}
@@ -606,20 +606,20 @@ modern_setup_queue(struct virtio_hw *hw, struct virtqueue
*vq)
ring[vq->vq_nentries]),
VIRTIO_PCI_VRING_ALIGN);
- io_write16(vq->vq_queue_index, &hw->common_cfg->queue_select);
+ io_write16(&hw->common_cfg->queue_select, vq->vq_queue_index);
- io_write64_twopart(desc_addr, &hw->common_cfg->queue_desc_lo,
- &hw->common_cfg->queue_desc_hi);
- io_write64_twopart(avail_addr, &hw->common_cfg->queue_avail_lo,
- &hw->common_cfg->queue_avail_hi);
- io_write64_twopart(used_addr, &hw->common_cfg->queue_used_lo,
- &hw->common_cfg->queue_used_hi);
+ io_write64_twopart(&hw->common_cfg->queue_desc_lo,
+ &hw->common_cfg->queue_desc_hi, desc_addr);
+ io_write64_twopart(&hw->common_cfg->queue_avail_lo,
+ &hw->common_cfg->queue_avail_hi, avail_addr);
+ io_write64_twopart(&hw->common_cfg->queue_used_lo,
+ &hw->common_cfg->que
[dpdk-dev] [PATCH 2/3] virtio: move rte_eal_pci_unmap_device() to virtio_pci.c
To abstract pci access method, the patch moves below function
to "virtio_pci.c".
- rte_eal_pci_unmap_device()
Signed-off-by: Tetsuya Mukawa
---
drivers/net/virtio/virtio_ethdev.c | 2 +-
drivers/net/virtio/virtio_pci.c| 11 +++
drivers/net/virtio/virtio_pci.h| 1 +
3 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/net/virtio/virtio_ethdev.c
b/drivers/net/virtio/virtio_ethdev.c
index deb0382..b98d195 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -1177,7 +1177,7 @@ eth_virtio_dev_uninit(struct rte_eth_dev *eth_dev)
rte_intr_callback_unregister(&pci_dev->intr_handle,
virtio_interrupt_handler,
eth_dev);
- rte_eal_pci_unmap_device(pci_dev);
+ vtpci_uninit(dev, hw)
PMD_INIT_LOG(DEBUG, "dev_uninit completed");
diff --git a/drivers/net/virtio/virtio_pci.c b/drivers/net/virtio/virtio_pci.c
index f1a6ee9..ffcd2fa 100644
--- a/drivers/net/virtio/virtio_pci.c
+++ b/drivers/net/virtio/virtio_pci.c
@@ -872,3 +872,14 @@ vtpci_init(struct rte_pci_device *dev, struct virtio_hw
*hw)
return 0;
}
+
+void
+vtpci_uninit(struct rte_pci_device *dev, struct virtio_hw *hw)
+{
+ hw->dev = NULL;
+ hw->vtpci_ops = NULL;
+ hw->use_msix = 0;
+ hw->io_base = 0;
+ hw->modern = 0;
+ rte_eal_pci_unmap_device(dev);
+}
diff --git a/drivers/net/virtio/virtio_pci.h b/drivers/net/virtio/virtio_pci.h
index 99572a0..ec1d46b 100644
--- a/drivers/net/virtio/virtio_pci.h
+++ b/drivers/net/virtio/virtio_pci.h
@@ -328,6 +328,7 @@ vtpci_with_feature(struct virtio_hw *hw, uint64_t bit)
* Function declaration from virtio_pci.c
*/
int vtpci_init(struct rte_pci_device *, struct virtio_hw *);
+void vtpci_uninit(struct rte_pci_device *dev, struct virtio_hw *);
void vtpci_reset(struct virtio_hw *);
void vtpci_reinit_complete(struct virtio_hw *);
--
2.1.4
[dpdk-dev] [PATCH 3/3] virtio: Add a new layer to abstract pci access method
This patch adds below function pointers to abstract pci access method.
- legacy_read8/16/32
- legacy_write8/16/32
- modern_read8/16/32
- modern_write8/16/32
- map_pci_cfg
- unmap_pci_cfg
- get_cfg_addr
- read_pci_cfg
This layer will be used when virtio-net PMD supports container extension.
The legacy_x are for handling legacy virtio-net device, and
the modern_x are for handling virtio-1.0 device.
This new layer also abstract how to access to pci configuration space.
Signed-off-by: Tetsuya Mukawa
---
drivers/net/virtio/virtio_ethdev.c | 4 +-
drivers/net/virtio/virtio_pci.c| 449 ++---
drivers/net/virtio/virtio_pci.h| 34 ++-
3 files changed, 354 insertions(+), 133 deletions(-)
diff --git a/drivers/net/virtio/virtio_ethdev.c
b/drivers/net/virtio/virtio_ethdev.c
index b98d195..c477b05 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -1037,7 +1037,7 @@ eth_virtio_dev_init(struct rte_eth_dev *eth_dev)
pci_dev = eth_dev->pci_dev;
- if (vtpci_init(pci_dev, hw) < 0)
+ if (vtpci_init(eth_dev, hw) < 0)
return -1;
/* Reset the device although not necessary at startup */
@@ -1177,7 +1177,7 @@ eth_virtio_dev_uninit(struct rte_eth_dev *eth_dev)
rte_intr_callback_unregister(&pci_dev->intr_handle,
virtio_interrupt_handler,
eth_dev);
- vtpci_uninit(dev, hw)
+ vtpci_uninit(eth_dev, hw);
PMD_INIT_LOG(DEBUG, "dev_uninit completed");
diff --git a/drivers/net/virtio/virtio_pci.c b/drivers/net/virtio/virtio_pci.c
index ffcd2fa..20b64eb 100644
--- a/drivers/net/virtio/virtio_pci.c
+++ b/drivers/net/virtio/virtio_pci.c
@@ -68,6 +68,190 @@
#define VIRTIO_WRITE_REG_4(hw, reg, value) \
outl_p((unsigned int)(value), (VIRTIO_PCI_REG_ADDR((hw), (reg
+static uint8_t
+phys_legacy_read8(struct virtio_hw *hw, uint8_t *addr)
+{
+ return VIRTIO_READ_REG_1(hw, (uint64_t)addr);
+}
+
+static uint16_t
+phys_legacy_read16(struct virtio_hw *hw, uint16_t *addr)
+{
+ return VIRTIO_READ_REG_2(hw, (uint64_t)addr);
+}
+
+static uint32_t
+phys_legacy_read32(struct virtio_hw *hw, uint32_t *addr)
+{
+ return VIRTIO_READ_REG_4(hw, (uint64_t)addr);
+}
+
+static void
+phys_legacy_write8(struct virtio_hw *hw, uint8_t *addr, uint8_t val)
+{
+ return VIRTIO_WRITE_REG_1(hw, (uint64_t)addr, val);
+}
+
+static void
+phys_legacy_write16(struct virtio_hw *hw, uint16_t *addr, uint16_t val)
+{
+ return VIRTIO_WRITE_REG_2(hw, (uint64_t)addr, val);
+}
+
+static void
+phys_legacy_write32(struct virtio_hw *hw, uint32_t *addr, uint32_t val)
+{
+ return VIRTIO_WRITE_REG_4(hw, (uint64_t)addr, val);
+}
+
+#define MODERN_READ_DEF(nr_bits, type) \
+static inline type \
+io_read##nr_bits(type *addr) \
+{ \
+ return *(volatile type *)addr; \
+}
+
+#define MODERN_WRITE_DEF(nr_bits, type)\
+static inline void \
+io_write##nr_bits(type *addr, type val)\
+{ \
+ *(volatile type *)addr = val; \
+}
+
+MODERN_READ_DEF (8, uint8_t)
+MODERN_WRITE_DEF(8, uint8_t)
+
+MODERN_READ_DEF (16, uint16_t)
+MODERN_WRITE_DEF(16, uint16_t)
+
+MODERN_READ_DEF (32, uint32_t)
+MODERN_WRITE_DEF(32, uint32_t)
+
+static uint8_t
+phys_modern_read8(struct virtio_hw *hw __rte_unused, uint8_t *addr)
+{
+ return io_read8((uint8_t *)addr);
+}
+
+static uint16_t
+phys_modern_read16(struct virtio_hw *hw __rte_unused, uint16_t *addr)
+{
+ return io_read16((uint16_t *)addr);
+}
+
+static uint32_t
+phys_modern_read32(struct virtio_hw *hw __rte_unused, uint32_t *addr)
+{
+ return io_read32((uint32_t *)addr);
+}
+
+static void
+phys_modern_write8(struct virtio_hw *hw __rte_unused,
+ uint8_t *addr, uint8_t val)
+{
+ return io_write8((uint8_t *)addr, val);
+}
+
+static void
+phys_modern_write16(struct virtio_hw *hw __rte_unused,
+ uint16_t *addr, uint16_t val)
+{
+ return io_write16((uint16_t *)addr, val);
+}
+
+static void
+phys_modern_write32(struct virtio_hw *hw __rte_unused,
+ uint32_t *addr, uint32_t val)
+{
+ return io_write32((uint32_t *)addr, val);
+}
+
+static int
+phys_map_pci_cfg(struct virtio_hw *hw)
+{
+ return rte_eal_pci_map_device(hw->dev);
+}
+
+static void
+phys_unmap_pci_cfg(struct virtio_hw *hw)
+{
+ rte_eal_pci_unmap_device(hw->dev);
+}
+
+static int
+phys_read_pci_cfg(struct virtio_hw *hw, void *buf, size_t len, off_t offset)
+{
+ return rte_eal_pci_read_config(hw->dev, buf, len, offset);
+}
+
+static void *
+phys_get_cfg_addr(struct virtio_hw *hw, struct virtio_pci_cap *cap)
+{
+ uint8_t bar= cap->bar;
+ uint32_t length = cap-
[dpdk-dev] [PATCH v5 1/2] tools: Add support for handling built-in kernel modules
ping?
W dniu 16.12.2015 o 15:14, Kamil Rytarowski pisze:
> ping?
>
> W dniu 09.12.2015 o 14:19, Kamil Rytarowski pisze:
>> Currently dpdk_nic_bind.py detects Linux kernel modules via reading
>> /proc/modules. Built-in ones aren't listed there and therefore they
>> are not
>> being found by the script.
>>
>> Add support for checking built-in modules with parsing the sysfs files.
>>
>> This commit obsoletes the /proc/modules parsing approach.
>>
>> Signed-off-by: Kamil Rytarowski
>> Signed-off-by: David Marchand
>> ---
>> tools/dpdk_nic_bind.py | 27 +--
>> 1 file changed, 17 insertions(+), 10 deletions(-)
>>
>> diff --git a/tools/dpdk_nic_bind.py b/tools/dpdk_nic_bind.py
>> index f02454e..e161062 100755
>> --- a/tools/dpdk_nic_bind.py
>> +++ b/tools/dpdk_nic_bind.py
>> @@ -156,22 +156,29 @@ def check_modules():
>> '''Checks that igb_uio is loaded'''
>> global dpdk_drivers
>> -fd = file("/proc/modules")
>> -loaded_mods = fd.readlines()
>> -fd.close()
>> -
>> # list of supported modules
>> mods = [{"Name" : driver, "Found" : False} for driver in
>> dpdk_drivers]
>> # first check if module is loaded
>> -for line in loaded_mods:
>> +try:
>> +# Get list of syfs modules, some of them might be builtin
>> and merge with mods
>> +sysfs_path = '/sys/module/'
>> +
>> +# Get the list of directories in sysfs_path
>> +sysfs_mods = [os.path.join(sysfs_path,o) for o in
>> os.listdir(sysfs_path) if os.path.isdir(os.path.join(sysfs_path,o))]
>> +
>> +# Extract the last element of '/sys/module/abc' in the array
>> +sysfs_mods = [a.split('/')[-1] for a in sysfs_mods]
>> +
>> +# special case for vfio_pci (module is named vfio-pci,
>> +# but its .ko is named vfio_pci)
>> +sysfs_mods = map(lambda a: a if a != 'vfio_pci' else
>> 'vfio-pci', sysfs_mods)
>> +
>> for mod in mods:
>> -if line.startswith(mod["Name"]):
>> -mod["Found"] = True
>> -# special case for vfio_pci (module is named vfio-pci,
>> -# but its .ko is named vfio_pci)
>> -elif line.replace("_", "-").startswith(mod["Name"]):
>> +if mod["Found"] == False and (mod["Name"] in sysfs_mods):
>> mod["Found"] = True
>> +except:
>> +pass
>> # check if we have at least one loaded module
>> if True not in [mod["Found"] for mod in mods] and b_flag is not
>> None:
>
[dpdk-dev] [PATCH 09/11] doc: refresh headers list
2016-01-16 16:10, David Marchand: > On Tue, Jan 12, 2016 at 3:06 PM, Mcnamara, John > wrote: > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of David Marchand > >> Since we are going to remove a header in next commit, let's first refresh > >> documentation. > > > > I don't like these parts of the docs that list files since they > > go out of date quite easily and, in general, the same information > > can be conveyed by just listing the directories. (That isn't > > future-proof either but it should be less subject to change.) +1 > > $ ls > > app tools > > configMAINTAINERS > > Makefile GNUmakefile > > drivers mk > > examples pkg > > doc README > > lib scripts > > LICENSE.GPL LICENSE.LGPL > > i686-native-linuxapp-gcc x86_64-native-linuxapp-gcc > > i686-native-linuxapp-icc x86_64-native-linuxapp-icc > > > > $ ls x86_64-native-linuxapp-gcc > > app build include kmod lib Makefile > > > > Well, from my pov, it is the same issue here. > How about just removing all those files listings ? > I am not sure they really help. +1
[dpdk-dev] [PATCH v2 00/10] kill global pci device id list
This patchset moves all pci device ids from eal to the pmds that need them (patches 1 to 8). Global pci device id list is then removed (patch 9). In last patch, all those device ids are put in a dedicated section for retrieval by external tools. Changes since v1: - indent fixes in i40e, fm10k, virtio, vmxnet3, enic, bnx2c. - rebased on head (ixgbe update) - removed doc update (will be sent separately) -- David Marchand David Marchand (10): e1000: move pci device ids to driver ixgbe: move pci device ids to driver i40e: move pci device ids to driver fm10k: move pci device ids to driver virtio: move pci device ids to driver vmxnet3: move pci device ids to driver enic: move pci device ids to driver bnx2x: move pci device ids to driver pci: no need for global device ids list pci: place all uio pci device ids in a dedicated section app/test-pmd/Makefile | 2 + app/test-pmd/cmdline.c | 2 +- app/test/Makefile | 4 + app/test/test_pci.c | 5 +- doc/api/doxy-api-index.md | 1 - drivers/crypto/qat/rte_qat_cryptodev.c | 2 +- drivers/net/bnx2x/bnx2x.c | 3 +- drivers/net/bnx2x/bnx2x_ethdev.c| 25 +- drivers/net/cxgbe/cxgbe_ethdev.c| 2 +- drivers/net/e1000/em_ethdev.c | 4 +- drivers/net/e1000/em_pci_dev_ids.h | 200 +++ drivers/net/e1000/igb_ethdev.c | 8 +- drivers/net/e1000/igb_pci_dev_ids.h | 164 ++ drivers/net/enic/enic_ethdev.c | 14 +- drivers/net/fm10k/fm10k_ethdev.c| 8 +- drivers/net/i40e/i40e_ethdev.c | 22 +- drivers/net/i40e/i40e_ethdev_vf.c | 10 +- drivers/net/ixgbe/ixgbe_ethdev.c| 8 +- drivers/net/ixgbe/ixgbe_pci_dev_ids.h | 191 +++ drivers/net/nfp/nfp_net.c | 2 +- drivers/net/virtio/virtio_ethdev.c | 9 +- drivers/net/vmxnet3/vmxnet3_ethdev.c| 11 +- lib/librte_eal/common/Makefile | 2 +- lib/librte_eal/common/include/rte_pci.h | 2 + lib/librte_eal/common/include/rte_pci_dev_ids.h | 669 lib/librte_eal/linuxapp/kni/Makefile| 2 + lib/librte_eal/linuxapp/kni/kni_misc.c | 8 +- 27 files changed, 648 insertions(+), 732 deletions(-) create mode 100644 drivers/net/e1000/em_pci_dev_ids.h create mode 100644 drivers/net/e1000/igb_pci_dev_ids.h create mode 100644 drivers/net/ixgbe/ixgbe_pci_dev_ids.h delete mode 100644 lib/librte_eal/common/include/rte_pci_dev_ids.h -- 1.9.1
[dpdk-dev] [PATCH v2 01/10] e1000: move pci device ids to driver
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.
Signed-off-by: David Marchand
---
app/test/Makefile | 3 +
app/test/test_pci.c | 3 +-
drivers/net/e1000/em_ethdev.c | 2 +-
drivers/net/e1000/em_pci_dev_ids.h | 200 +++
drivers/net/e1000/igb_ethdev.c | 4 +-
drivers/net/e1000/igb_pci_dev_ids.h | 164
lib/librte_eal/common/include/rte_pci_dev_ids.h | 245
lib/librte_eal/linuxapp/kni/Makefile| 1 +
lib/librte_eal/linuxapp/kni/kni_misc.c | 4 +-
9 files changed, 375 insertions(+), 251 deletions(-)
create mode 100644 drivers/net/e1000/em_pci_dev_ids.h
create mode 100644 drivers/net/e1000/igb_pci_dev_ids.h
diff --git a/app/test/Makefile b/app/test/Makefile
index ec33e1a..687ae59 100644
--- a/app/test/Makefile
+++ b/app/test/Makefile
@@ -168,6 +168,9 @@ CFLAGS_test_memcpy_perf.o += -fno-var-tracking-assignments
endif
endif
+# pci tests want to know some pci devices ids
+CFLAGS_test_pci.o += -I$(RTE_SDK)/drivers/net/e1000
+
# this application needs libraries first
DEPDIRS-y += lib drivers
diff --git a/app/test/test_pci.c b/app/test/test_pci.c
index 5530d99..b289138 100644
--- a/app/test/test_pci.c
+++ b/app/test/test_pci.c
@@ -77,8 +77,9 @@ struct rte_pci_id my_driver_id2[] = {
/* IGB & EM NICS */
#define RTE_PCI_DEV_ID_DECL_EM(vend, dev) {RTE_PCI_DEVICE(vend, dev)},
+#include
#define RTE_PCI_DEV_ID_DECL_IGB(vend, dev) {RTE_PCI_DEVICE(vend, dev)},
-#include
+#include
{ .vendor_id = 0, /* sentinel */ },
};
diff --git a/drivers/net/e1000/em_ethdev.c b/drivers/net/e1000/em_ethdev.c
index 66e8993..4cf9217 100644
--- a/drivers/net/e1000/em_ethdev.c
+++ b/drivers/net/e1000/em_ethdev.c
@@ -139,7 +139,7 @@ static enum e1000_fc_mode em_fc_setting = e1000_fc_full;
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"
+#include "em_pci_dev_ids.h"
{0},
};
diff --git a/drivers/net/e1000/em_pci_dev_ids.h
b/drivers/net/e1000/em_pci_dev_ids.h
new file mode 100644
index 000..c79697b
--- /dev/null
+++ b/drivers/net/e1000/em_pci_dev_ids.h
@@ -0,0 +1,200 @@
+/*-
+ * This file is provided under a dual BSD/GPLv2 license. When using or
+ * redistributing this file, you may do so under either license.
+ *
+ * GPL LICENSE SUMMARY
+ *
+ * Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * The full GNU General Public License is included in this distribution
+ * in the file called LICENSE.GPL.
+ *
+ * Contact Information:
+ * Intel Corporation
+ *
+ * BSD LICENSE
+ *
+ * Copyright(c) 2010-2014 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.
+ *
+ */
+
[dpdk-dev] [PATCH v2 02/10] ixgbe: move pci device ids to driver
test application and kni still want to know ixgbe pci devices.
So let's create a header in the driver that will be used by them.
Signed-off-by: David Marchand
---
app/test-pmd/Makefile | 2 +
app/test-pmd/cmdline.c | 2 +-
app/test/Makefile | 1 +
app/test/test_pci.c | 2 +-
drivers/net/ixgbe/ixgbe_ethdev.c| 4 +-
drivers/net/ixgbe/ixgbe_pci_dev_ids.h | 191
lib/librte_eal/common/include/rte_pci_dev_ids.h | 132
lib/librte_eal/linuxapp/kni/Makefile| 1 +
lib/librte_eal/linuxapp/kni/kni_misc.c | 4 +-
9 files changed, 201 insertions(+), 138 deletions(-)
create mode 100644 drivers/net/ixgbe/ixgbe_pci_dev_ids.h
diff --git a/app/test-pmd/Makefile b/app/test-pmd/Makefile
index 72426f3..a8899b8 100644
--- a/app/test-pmd/Makefile
+++ b/app/test-pmd/Makefile
@@ -64,6 +64,8 @@ ifeq ($(CONFIG_RTE_EXEC_ENV_LINUXAPP),y)
CFLAGS_mempool_anon.o := -D_GNU_SOURCE
endif
CFLAGS_cmdline.o := -D_GNU_SOURCE
+# for bypass pci device ids
+CFLAGS_cmdline.o += -I$(RTE_SDK)/drivers/net/ixgbe
# this application needs libraries first
DEPDIRS-y += lib drivers
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 73298c9..fdb2e1b 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -9816,7 +9816,7 @@ cmd_reconfig_device_queue(portid_t id, uint8_t dev,
uint8_t queue)
}
#ifdef RTE_NIC_BYPASS
-#include
+#include
uint8_t
bypass_is_supported(portid_t port_id)
{
diff --git a/app/test/Makefile b/app/test/Makefile
index 687ae59..13fed78 100644
--- a/app/test/Makefile
+++ b/app/test/Makefile
@@ -170,6 +170,7 @@ endif
# pci tests want to know some pci devices ids
CFLAGS_test_pci.o += -I$(RTE_SDK)/drivers/net/e1000
+CFLAGS_test_pci.o += -I$(RTE_SDK)/drivers/net/ixgbe
# this application needs libraries first
DEPDIRS-y += lib drivers
diff --git a/app/test/test_pci.c b/app/test/test_pci.c
index b289138..d6a23d6 100644
--- a/app/test/test_pci.c
+++ b/app/test/test_pci.c
@@ -68,7 +68,7 @@ static int my_driver_init(struct rte_pci_driver *dr,
struct rte_pci_id my_driver_id[] = {
#define RTE_PCI_DEV_ID_DECL_IXGBE(vend, dev) {RTE_PCI_DEVICE(vend, dev)},
-#include
+#include
{ .vendor_id = 0, /* sentinel */ },
};
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index 4c4c6df..b31f52e 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -381,7 +381,7 @@ static int ixgbe_timesync_write_time(struct rte_eth_dev
*dev,
static const struct rte_pci_id pci_id_ixgbe_map[] = {
#define RTE_PCI_DEV_ID_DECL_IXGBE(vend, dev) {RTE_PCI_DEVICE(vend, dev)},
-#include "rte_pci_dev_ids.h"
+#include "ixgbe_pci_dev_ids.h"
{ .vendor_id = 0, /* sentinel */ },
};
@@ -393,7 +393,7 @@ static const struct rte_pci_id pci_id_ixgbe_map[] = {
static const struct rte_pci_id pci_id_ixgbevf_map[] = {
#define RTE_PCI_DEV_ID_DECL_IXGBEVF(vend, dev) {RTE_PCI_DEVICE(vend, dev)},
-#include "rte_pci_dev_ids.h"
+#include "ixgbe_pci_dev_ids.h"
{ .vendor_id = 0, /* sentinel */ },
};
diff --git a/drivers/net/ixgbe/ixgbe_pci_dev_ids.h
b/drivers/net/ixgbe/ixgbe_pci_dev_ids.h
new file mode 100644
index 000..e2da88a
--- /dev/null
+++ b/drivers/net/ixgbe/ixgbe_pci_dev_ids.h
@@ -0,0 +1,191 @@
+/*-
+ * This file is provided under a dual BSD/GPLv2 license. When using or
+ * redistributing this file, you may do so under either license.
+ *
+ * GPL LICENSE SUMMARY
+ *
+ * Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * The full GNU General Public License is included in this distribution
+ * in the file called LICENSE.GPL.
+ *
+ * Contact Information:
+ * Intel Corporation
+ *
+ * BSD LICENSE
+ *
+ * Copyright(c) 2010-2014 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
[dpdk-dev] [PATCH v2 03/10] i40e: move pci device ids to driver
Since the base driver already defines all pci device ids, no need to
redefine them, let's just drop the previous RTE_PCI_DEV_ID_DECL* stuff.
Signed-off-by: David Marchand
---
Changes since v1:
- indent fix
drivers/net/i40e/i40e_ethdev.c | 20 +++--
drivers/net/i40e/i40e_ethdev_vf.c | 8 ++--
lib/librte_eal/common/include/rte_pci_dev_ids.h | 60 -
3 files changed, 22 insertions(+), 66 deletions(-)
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index bf6220d..e9f6587 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -416,9 +416,23 @@ static int i40e_dev_rx_queue_intr_disable(struct
rte_eth_dev *dev,
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_A) },
+ { 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_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 14d2a50..9302f27 100644
--- a/drivers/net/i40e/i40e_ethdev_vf.c
+++ b/drivers/net/i40e/i40e_ethdev_vf.c
@@ -1117,9 +1117,11 @@ 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_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 ab6c4fb..f1f3e13 100644
--- a/lib/librte_eal/common/include/rte_pci_dev_ids.h
+++ b/lib/librte_eal/common/include/rte_pci_dev_ids.h
@@ -68,8 +68,6 @@
* 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_I40E
- * RTE_PCI_DEV_ID_DECL_I40EVF
* RTE_PCI_DEV_ID_DECL_VIRTIO
* at the time when this file is included.
*
@@ -91,14 +89,6 @@
* Note that this file can be included multiple times within the same file.
*/
-#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
@@ -152,42 +142,6 @@
#define PCI_VENDOR_ID_BROADCOM 0x14E4
#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_A0x157F
-#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_X722_A0 0x374C
-#define I40E_DEV_ID_SFP_X7220x37D0
-#define I40E_DEV_ID_1G_BASE_T_X722 0x37D1
-#define I40E_DEV_ID_10G_BASE_T_X722 0x37D2
-
-RTE_PCI_DEV_ID_DECL_I40E(PCI_VENDOR_ID_INTEL, I40E_DEV_ID_SFP_XL710)
-RTE_PCI_DEV_ID_DECL_I40
[dpdk-dev] [PATCH v2 04/10] fm10k: move pci device ids to driver
Since the base driver already defines all pci device ids, no need to
redefine them, let's just drop the previous RTE_PCI_DEV_ID_DECL* stuff.
Signed-off-by: David Marchand
---
Changes since v1:
- indent fix
drivers/net/fm10k/fm10k_ethdev.c| 6 ++---
lib/librte_eal/common/include/rte_pci_dev_ids.h | 29 -
2 files changed, 3 insertions(+), 32 deletions(-)
diff --git a/drivers/net/fm10k/fm10k_ethdev.c b/drivers/net/fm10k/fm10k_ethdev.c
index e4aed94..2c4905c 100644
--- a/drivers/net/fm10k/fm10k_ethdev.c
+++ b/drivers/net/fm10k/fm10k_ethdev.c
@@ -2741,9 +2741,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 f1f3e13..a19fdfa 100644
--- a/lib/librte_eal/common/include/rte_pci_dev_ids.h
+++ b/lib/librte_eal/common/include/rte_pci_dev_ids.h
@@ -97,14 +97,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
@@ -117,11 +109,6 @@
#define RTE_PCI_DEV_ID_DECL_BNX2XVF(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_QUMRANET
/** Vendor ID used by virtio devices */
#define PCI_VENDOR_ID_QUMRANET 0x1AF4
@@ -142,14 +129,6 @@
#define PCI_VENDOR_ID_BROADCOM 0x14E4
#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)
-
/** Virtio devices from virtio.h **/
#define QUMRANET_DEV_ID_VIRTIO 0x1000
@@ -162,12 +141,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 */
@@ -228,5 +201,3 @@ RTE_PCI_DEV_ID_DECL_BNX2X(PCI_VENDOR_ID_BROADCOM,
BNX2X_DEV_ID_57840_MF)
#undef RTE_PCI_DEV_ID_DECL_BNX2XVF
#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
--
1.9.1
[dpdk-dev] [PATCH v2 05/10] virtio: move pci device ids to driver
Reused defines from virtio_pci.h.
Signed-off-by: David Marchand
---
Changes since v1:
- indent fix
drivers/net/virtio/virtio_ethdev.c | 7 ++-
lib/librte_eal/common/include/rte_pci_dev_ids.h | 17 -
2 files changed, 2 insertions(+), 22 deletions(-)
diff --git a/drivers/net/virtio/virtio_ethdev.c
b/drivers/net/virtio/virtio_ethdev.c
index d928339..94486e6 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -106,11 +106,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 a19fdfa..448b5e1 100644
--- a/lib/librte_eal/common/include/rte_pci_dev_ids.h
+++ b/lib/librte_eal/common/include/rte_pci_dev_ids.h
@@ -68,7 +68,6 @@
* 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_VIRTIO
* at the time when this file is included.
*
* In order to populate an array, the user of this file must define this macro:
@@ -89,10 +88,6 @@
* Note that this file can be included multiple times within the same file.
*/
-#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
@@ -109,11 +104,6 @@
#define RTE_PCI_DEV_ID_DECL_BNX2XVF(vend, dev)
#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
@@ -129,12 +119,6 @@
#define PCI_VENDOR_ID_BROADCOM 0x14E4
#endif
-/** 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
@@ -199,5 +183,4 @@ RTE_PCI_DEV_ID_DECL_BNX2X(PCI_VENDOR_ID_BROADCOM,
BNX2X_DEV_ID_57840_MF)
*/
#undef RTE_PCI_DEV_ID_DECL_BNX2X
#undef RTE_PCI_DEV_ID_DECL_BNX2XVF
-#undef RTE_PCI_DEV_ID_DECL_VIRTIO
#undef RTE_PCI_DEV_ID_DECL_VMXNET3
--
1.9.1
[dpdk-dev] [PATCH v2 06/10] vmxnet3: move pci device ids to driver
Moved vmware device ids macro since the driver had no such information.
Signed-off-by: David Marchand
---
Changes since v1:
- indent fix
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 c363bf6..304f076 100644
--- a/drivers/net/vmxnet3/vmxnet3_ethdev.c
+++ b/drivers/net/vmxnet3/vmxnet3_ethdev.c
@@ -98,12 +98,11 @@ static void vmxnet3_process_events(struct vmxnet3_hw *);
/*
* The set of PCI devices this driver supports
*/
+#define PCI_VENDOR_ID_VMWARE 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(PCI_VENDOR_ID_VMWARE, 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 448b5e1..0ecff3c 100644
--- a/lib/librte_eal/common/include/rte_pci_dev_ids.h
+++ b/lib/librte_eal/common/include/rte_pci_dev_ids.h
@@ -88,10 +88,6 @@
* Note that this file can be included multiple times within the same file.
*/
-#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
@@ -104,11 +100,6 @@
#define RTE_PCI_DEV_ID_DECL_BNX2XVF(vend, dev)
#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
@@ -119,12 +110,6 @@
#define PCI_VENDOR_ID_BROADCOM 0x14E4
#endif
-/** 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 */
@@ -183,4 +168,3 @@ RTE_PCI_DEV_ID_DECL_BNX2X(PCI_VENDOR_ID_BROADCOM,
BNX2X_DEV_ID_57840_MF)
*/
#undef RTE_PCI_DEV_ID_DECL_BNX2X
#undef RTE_PCI_DEV_ID_DECL_BNX2XVF
-#undef RTE_PCI_DEV_ID_DECL_VMXNET3
--
1.9.1
[dpdk-dev] [PATCH v2 07/10] enic: move pci device ids to driver
Moved cisco vendor id since the driver had no such information.
Signed-off-by: David Marchand
---
Changes since v1:
- indent fix
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 2a88043..a70c364 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 PCI_VENDOR_ID_CISCO 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(PCI_VENDOR_ID_CISCO, PCI_DEVICE_ID_CISCO_VIC_ENET) },
+ { RTE_PCI_DEVICE(PCI_VENDOR_ID_CISCO, 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 0ecff3c..1c22c04 100644
--- a/lib/librte_eal/common/include/rte_pci_dev_ids.h
+++ b/lib/librte_eal/common/include/rte_pci_dev_ids.h
@@ -88,10 +88,6 @@
* Note that this file can be included multiple times within the same file.
*/
-#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
@@ -100,24 +96,11 @@
#define RTE_PCI_DEV_ID_DECL_BNX2XVF(vend, dev)
#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
#endif
-/** 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 v2 08/10] bnx2x: move pci device ids to driver
Reused defines from the driver and moved broadcom vendor id macro.
Signed-off-by: David Marchand
---
Changes since v1:
- indent fix
drivers/net/bnx2x/bnx2x.c | 3 +-
drivers/net/bnx2x/bnx2x_ethdev.c| 21 +++--
lib/librte_eal/common/include/rte_pci_dev_ids.h | 60 -
3 files changed, 18 insertions(+), 66 deletions(-)
diff --git a/drivers/net/bnx2x/bnx2x.c b/drivers/net/bnx2x/bnx2x.c
index 67af5da..bf6dd71 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
@@ -9592,7 +9591,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 69df02e..7655124 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 PCI_VENDOR_ID_BROADCOM 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(PCI_VENDOR_ID_BROADCOM, CHIP_NUM_57800) },
+ { RTE_PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, CHIP_NUM_57711) },
+ { RTE_PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, CHIP_NUM_57810) },
+ { RTE_PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, CHIP_NUM_57811) },
+ { RTE_PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, CHIP_NUM_57840_OBS) },
+ { RTE_PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, CHIP_NUM_57840_4_10) },
+ { RTE_PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, CHIP_NUM_57840_2_20) },
+#ifdef RTE_LIBRTE_BNX2X_MF_SUPPORT
+ { RTE_PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, CHIP_NUM_57810_MF) },
+ { RTE_PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, CHIP_NUM_57811_MF) },
+ { RTE_PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 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(PCI_VENDOR_ID_BROADCOM, CHIP_NUM_57800_VF) },
+ { RTE_PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, CHIP_NUM_57810_VF) },
+ { RTE_PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, CHIP_NUM_57811_VF) },
+ { RTE_PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 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 1c22c04..6720b7a 100644
--- a/lib/librte_eal/common/include/rte_pci_dev_ids.h
+++ b/lib/librte_eal/common/include/rte_pci_dev_ids.h
@@ -88,66 +88,6 @@
* Note that this file can be included multiple times within the same file.
*/
-#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 PCI_VENDOR_ID_BROADCOM
-/** Vendor ID used by Broadcom devices */
-#define PCI_VENDOR_ID_BROADCOM 0x14E4
-#endif
-
-/** 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_BROADCOM, BNX2X_DEV_ID_57810_VF)
-RTE_PCI_DEV_ID_DECL_BNX2X(PCI_VENDOR_ID_BROADCOM, BNX2X_DEV_ID_57811)
-RTE_PCI_DEV_ID_DECL_BNX2XVF(PCI_VENDOR_ID_BROADCOM, BNX2X_DEV_ID_57811_VF)
-RTE_PCI_DEV_ID_DECL_BNX2X(PCI_VENDOR_ID_BROAD
[dpdk-dev] [PATCH v2 09/10] pci: no need for global device ids list
Now that all pci device ids are in their respective drivers, we can remove this header. Signed-off-by: David Marchand --- doc/api/doxy-api-index.md | 1 - lib/librte_eal/common/Makefile | 2 +- lib/librte_eal/common/include/rte_pci_dev_ids.h | 93 - 3 files changed, 1 insertion(+), 95 deletions(-) delete mode 100644 lib/librte_eal/common/include/rte_pci_dev_ids.h diff --git a/doc/api/doxy-api-index.md b/doc/api/doxy-api-index.md index 7a91001..0540aba 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/Makefile b/lib/librte_eal/common/Makefile index f5ea0ee..bb9810d 100644 --- a/lib/librte_eal/common/Makefile +++ b/lib/librte_eal/common/Makefile @@ -34,7 +34,7 @@ include $(RTE_SDK)/mk/rte.vars.mk INC := rte_branch_prediction.h rte_common.h INC += rte_debug.h rte_eal.h rte_errno.h rte_launch.h rte_lcore.h INC += rte_log.h rte_memory.h rte_memzone.h rte_pci.h -INC += rte_pci_dev_ids.h rte_per_lcore.h rte_random.h +INC += rte_per_lcore.h rte_random.h INC += rte_tailq.h rte_interrupts.h rte_alarm.h INC += rte_string_fns.h rte_version.h INC += rte_eal_memconfig.h rte_malloc_heap.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 deleted file mode 100644 index 6720b7a..000 --- a/lib/librte_eal/common/include/rte_pci_dev_ids.h +++ /dev/null @@ -1,93 +0,0 @@ -/*- - * This file is provided under a dual BSD/GPLv2 license. When using or - * redistributing this file, you may do so under either license. - * - * GPL LICENSE SUMMARY - * - * Copyright(c) 2010-2015 Intel Corporation. All rights reserved. - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of version 2 of the GNU General Public License as - * published by the Free Software Foundation. - * - * This program is distributed in the hope that it will be useful, but - * WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU - * General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA. - * The full GNU General Public License is included in this distribution - * in the file called LICENSE.GPL. - * - * Contact Information: - * Intel Corporation - * - * BSD LICENSE - * - * Copyright(c) 2010-2014 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. - * - */ - -/** - * @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 four families of devices are recognised: those supported by the - * IGB driver, by EM driver, those supported by the IXGBE driver, and by virtio - * driver which is a para vir
[dpdk-dev] [PATCH v2 10/10] pci: place all uio pci device ids in a dedicated section
We could do something ? la modinfo, but let's keep it simple for now.
With this, you can extract the devices that need to be bound to uio / vfio
with tools like objdump :
$ objdump -j rte_pci_id_uio -s build/lib/librte_pmd_fm10k.so
Contents of section rte_pci_id_uio:
15760 8680a415 8680d015
15770 8680a515
Signed-off-by: David Marchand
---
drivers/crypto/qat/rte_qat_cryptodev.c | 2 +-
drivers/net/bnx2x/bnx2x_ethdev.c| 4 ++--
drivers/net/cxgbe/cxgbe_ethdev.c| 2 +-
drivers/net/e1000/em_ethdev.c | 2 +-
drivers/net/e1000/igb_ethdev.c | 4 ++--
drivers/net/enic/enic_ethdev.c | 2 +-
drivers/net/fm10k/fm10k_ethdev.c| 2 +-
drivers/net/i40e/i40e_ethdev.c | 2 +-
drivers/net/i40e/i40e_ethdev_vf.c | 2 +-
drivers/net/ixgbe/ixgbe_ethdev.c| 4 ++--
drivers/net/nfp/nfp_net.c | 2 +-
drivers/net/virtio/virtio_ethdev.c | 2 +-
drivers/net/vmxnet3/vmxnet3_ethdev.c| 2 +-
lib/librte_eal/common/include/rte_pci.h | 2 ++
14 files changed, 18 insertions(+), 16 deletions(-)
diff --git a/drivers/crypto/qat/rte_qat_cryptodev.c
b/drivers/crypto/qat/rte_qat_cryptodev.c
index e500c1e..c9f5790 100644
--- a/drivers/crypto/qat/rte_qat_cryptodev.c
+++ b/drivers/crypto/qat/rte_qat_cryptodev.c
@@ -67,7 +67,7 @@ static struct rte_cryptodev_ops crypto_qat_ops = {
* The set of PCI devices this driver supports
*/
-static struct rte_pci_id pci_id_qat_map[] = {
+static struct rte_pci_id RTE_PCI_ID_UIO_SECTION pci_id_qat_map[] = {
{
.vendor_id = 0x8086,
.device_id = 0x0443,
diff --git a/drivers/net/bnx2x/bnx2x_ethdev.c b/drivers/net/bnx2x/bnx2x_ethdev.c
index 7655124..72546bd 100644
--- a/drivers/net/bnx2x/bnx2x_ethdev.c
+++ b/drivers/net/bnx2x/bnx2x_ethdev.c
@@ -17,7 +17,7 @@
* The set of PCI devices this driver supports
*/
#define PCI_VENDOR_ID_BROADCOM 0x14E4
-static struct rte_pci_id pci_id_bnx2x_map[] = {
+static struct rte_pci_id RTE_PCI_ID_UIO_SECTION pci_id_bnx2x_map[] = {
{ RTE_PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, CHIP_NUM_57800) },
{ RTE_PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, CHIP_NUM_57711) },
{ RTE_PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, CHIP_NUM_57810) },
@@ -33,7 +33,7 @@ static struct rte_pci_id pci_id_bnx2x_map[] = {
{ .vendor_id = 0, }
};
-static struct rte_pci_id pci_id_bnx2xvf_map[] = {
+static struct rte_pci_id RTE_PCI_ID_UIO_SECTION pci_id_bnx2xvf_map[] = {
{ RTE_PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, CHIP_NUM_57800_VF) },
{ RTE_PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, CHIP_NUM_57810_VF) },
{ RTE_PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, CHIP_NUM_57811_VF) },
diff --git a/drivers/net/cxgbe/cxgbe_ethdev.c b/drivers/net/cxgbe/cxgbe_ethdev.c
index 97ef152..2620130 100644
--- a/drivers/net/cxgbe/cxgbe_ethdev.c
+++ b/drivers/net/cxgbe/cxgbe_ethdev.c
@@ -68,7 +68,7 @@
* Macros needed to support the PCI Device ID Table ...
*/
#define CH_PCI_DEVICE_ID_TABLE_DEFINE_BEGIN \
- static struct rte_pci_id cxgb4_pci_tbl[] = {
+ static struct rte_pci_id RTE_PCI_ID_UIO_SECTION cxgb4_pci_tbl[] = {
#define CH_PCI_DEVICE_ID_FUNCTION 0x4
#define PCI_VENDOR_ID_CHELSIO 0x1425
diff --git a/drivers/net/e1000/em_ethdev.c b/drivers/net/e1000/em_ethdev.c
index 4cf9217..fb71686 100644
--- a/drivers/net/e1000/em_ethdev.c
+++ b/drivers/net/e1000/em_ethdev.c
@@ -136,7 +136,7 @@ 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[] = {
+static const struct rte_pci_id RTE_PCI_ID_UIO_SECTION pci_id_em_map[] = {
#define RTE_PCI_DEV_ID_DECL_EM(vend, dev) {RTE_PCI_DEVICE(vend, dev)},
#include "em_pci_dev_ids.h"
diff --git a/drivers/net/e1000/igb_ethdev.c b/drivers/net/e1000/igb_ethdev.c
index 3f85a2c..f71bcd1 100644
--- a/drivers/net/e1000/igb_ethdev.c
+++ b/drivers/net/e1000/igb_ethdev.c
@@ -273,7 +273,7 @@ static enum e1000_fc_mode igb_fc_setting = e1000_fc_full;
/*
* The set of PCI devices this driver supports
*/
-static const struct rte_pci_id pci_id_igb_map[] = {
+static const struct rte_pci_id RTE_PCI_ID_UIO_SECTION pci_id_igb_map[] = {
#define RTE_PCI_DEV_ID_DECL_IGB(vend, dev) {RTE_PCI_DEVICE(vend, dev)},
#include "igb_pci_dev_ids.h"
@@ -284,7 +284,7 @@ static const struct rte_pci_id pci_id_igb_map[] = {
/*
* The set of PCI devices this driver supports (for 82576&I350 VF)
*/
-static const struct rte_pci_id pci_id_igbvf_map[] = {
+static const struct rte_pci_id RTE_PCI_ID_UIO_SECTION pci_id_igbvf_map[] = {
#define RTE_PCI_DEV_ID_DECL_IGBVF(vend, dev) {RTE_PCI_DEVICE(vend, dev)},
#include "igb_pci_dev_ids.h"
diff --git a/drivers/net/enic/enic_ethdev.c b/drivers/net/enic/enic_ethdev.c
index a70c364..493b154 100644
--- a/drivers/net/enic/enic_ethdev.c
+++ b/drivers/net/enic/enic_ethdev.c
@@ -58,7 +58,7 @@
* The set of P
[dpdk-dev] [PATCH] cfgfile: support looking up sections by index
On 01/17/2016 05:58 AM, Rich Lane wrote: > This is useful when sections have duplicate names. > > Signed-off-by: Rich Lane > --- > lib/librte_cfgfile/rte_cfgfile.c | 16 > lib/librte_cfgfile/rte_cfgfile.h | 23 +++ > 2 files changed, 39 insertions(+) > This is missing the corresponding entry to lib/librte_cfgfile/rte_cfgfile_version.map - Panu -
[dpdk-dev] [PATCH v4 08/14] virtio: pci: extend virtio pci rw api for vfio interface
On Mon, Jan 18, 2016 at 12:47 PM, Yuanhan Liu wrote: > On Mon, Jan 18, 2016 at 12:15:40PM +0530, Santosh Shukla wrote: >> I am testing for virtio 1.0 and 0.95 for arm including your patch, >> soon we;ll post the patch series that is rebased on / dependent on >> below patchset: >> - virtio 1.0 >> - vfio-noiommu >> - KDRV check by huawei >> >> IMO, we should start merging the dependent patches as because I'll > > Yep, agreed. That's why I was keep pushing Huawei for ACK and > validation team for testing, although I have tested that. :) > >> have to rebase, then do regression across the platform at least for >> x86/arm64 and it's quite a work now. >> >> Beside that I have few question specific to vfio in virtio pmd driver; >> - vfio don't need resource_init functionality as it uses struct >> rte_pci_dev but it need parsing so to make sure >> 1. user has setted no_iommu mode >> 2. virtio pci device attached to vfio-no-iommu driver or not. >> >> So for 1) I am thinking to add RTE_KDRV_VFIO_NOIOMMU mode and a helper >> function like pci_vfio_is_iommu(), such that pc_xxx_scan() function >> updates dev->kdrv with RTE_KDRV_VFIO_NOIOMMU at driver probe time. > > That sounds better to me. And that's also what I want to comment on > your another patch [09/14], that we should try to avoid getting UIO/VFIO > stuff inside virtio pmd driver, unless it's a must. (yes, I know > UIO is already an example here, but I don't like it, and badly, I don't > have the time to check if I can remove it.) > Understood, So I'm moving possible required driver/parsing check in eal_pci.c rather keeping it in virtio, as those parsing/driver dependency checks are generic, has nothing to do with virtio. >> >> case 2) would check for _noiommu mode and then would verify that >> driver is attached or not? > > Sorry, very limited VFIO and noiommu knowledge, and I can't answer, so > far. > > --yliu >> >> above two case applicable to both virtio spec 1.0 and 0.95. I have >> done changes for those two case for v5 patch series,l any comment >> welcome before I push patch for review. >> >> Thanks.
[dpdk-dev] [PATCH 0/3] virtio: Add a new layer to abstract pci access method
Hi Tetsuya, On 1/18/2016 5:13 PM, Tetsuya Mukawa wrote: > The patches abstract pci access method of virtio-net PMD. > The patch should be on Yuanhan's below patch series. > - [PATCH v4 0/8] virtio 1.0 enabling for virtio pmd driver > > > Tetsuya Mukawa (3): >virtio: Change the parameter order of io_write8/16/32() >virtio: move rte_eal_pci_unmap_device() to virtio_pci.c >virtio: Add a new layer to abstract pci access method > > drivers/net/virtio/virtio_ethdev.c | 4 +- > drivers/net/virtio/virtio_pci.c| 468 > ++--- > drivers/net/virtio/virtio_pci.h| 33 ++- > 3 files changed, 369 insertions(+), 136 deletions(-) > Now I believe we will become more clear about the difference of our two implementations. I was planning to just implement another struct virtio_pci_ops because it's going the long way round for my implementation to translate virtio_pci_ops to ioport/pci configuration space rd/wr then back to sendmsg/ioctl. And in my implementation, there's no need to differentiate legacy/modern device. As I understand, your implementation does not need another implementation of struct virtio_pci_ops, but you need different implementation in lower layer as this patch show. You want to support both legacy/modern device, right? By the way, this patch looks good to me. Thanks, Jianfeng
[dpdk-dev] [PATCH v1] Modify and modularize l3fwd code
> From: Ravi Kerur [mailto:rkerur at gmail.com] > Sent: Monday, December 21, 2015 11:13 PM > To: dev at dpdk.org > Cc: Richardson, Bruce; Doherty, Declan; Ananyev, Konstantin; Ravi Kerur > Subject: [PATCH v1] Modify and modularize l3fwd code > > v1: > > Rebase to latest code base for DPDK team review. > > Intel team's (Konstantin, Bruce and Declan) review comments > > v4<-v3: > > Fix code review comments from Konstantin > > Move buffer optimization code into l3fwd_lpm_sse.h > and l3fwd_em_sse.h for LPM and EM respectively > > Add compile time __SSE4_1__ for header file inclusion > > Tested with CONFIG_RTE_MACHINE=default for non > __SSE4_1__ compilation and build > > Compiled for GCC 4.8.4 and 5.1 on Ubuntu 14.04 > > v3<-v2: > > Fix code review comments from Bruce > > Fix multiple static definitions > > Move local #defines to C files, common #defines > to H file. > > Rename ipv4_l3fwd_route to ipv4_l3fwd_lpm and ipv4_l3fwd_em > > Rename ipv6_l3fwd_route to ipv6_l3fwd_lpm and ipv6_l3fwd_lpm > > Pass additional parameter to send_single_packet > > Compiled for GCC 4.8.4 and 5.1 on Ubuntu 14.04 > > v2<-v1: > > Fix errors in GCC 5.1 > > Restore "static inline" functions, rearrange > functions to take "static inline" into account > > Duplicate main_loop for LPM and EM > > v1: > > Split main.c into following 3 files > > main.c, (parsing, buffer alloc, and other utilities) > > l3fwd_lpm.c, (Longest Prefix Match functions) > > l3fwd_em.c, (Exact Match f.e. Hash functions) > > l3fwd.h, (Common defines and prototypes) > > > Select LPM or EM based on run time selection f.e. > > l3fwd -c 0x1 -n 1 -- -p 0x1 -E ... (Exact Match) > > l3fwd -c 0x1 -n 1 -- -p 0x1 -L ... (LPM) > > > Options "E" and "L" are mutualy-exclusive. > > > Use function pointers during initialiation of relevant > data structures. > > > Remove unwanted #ifdefs in the code with exception to > > DO_RFC_1812_CHECKS > > RTE_MACHINE_CPUFLAG_SSE4_2 > > > Compiled for > > i686-native-linuxapp-gcc > > x86_64-native-linuxapp-gcc > > x86_x32-native-linuxapp-gcc > > x86_64-native-bsdapp-gcc > > > Tested on > > Ubuntu 14.04 (GCC 4.8.4) > > FreeBSD 10.0 (GCC 4.8) > > I217 and I218 respectively. > > Signed-off-by: Ravi Kerur > --- Acked-by: Konstantin Ananyev Great effort, thanks for doing it.
[dpdk-dev] [PATCH 3/3] virtio: Add a new layer to abstract pci access method
On Mon, Jan 18, 2016 at 06:13:09PM +0900, Tetsuya Mukawa wrote:
> +struct virtio_pci_access_ops {
> + uint8_t (*legacy_read8)(struct virtio_hw *hw, uint8_t *addr);
> + uint16_t (*legacy_read16)(struct virtio_hw *hw, uint16_t *addr);
> + uint32_t (*legacy_read32)(struct virtio_hw *hw, uint32_t *addr);
> + void (*legacy_write8)(struct virtio_hw *hw,
> + uint8_t *addr, uint8_t val);
> + void (*legacy_write16)(struct virtio_hw *hw,
> + uint16_t *addr, uint16_t val);
> + void (*legacy_write32)(struct virtio_hw *hw,
> + uint32_t *addr, uint32_t val);
> +
> + uint8_t (*modern_read8)(struct virtio_hw *hw, uint8_t *addr);
> + uint16_t (*modern_read16)(struct virtio_hw *hw, uint16_t *addr);
> + uint32_t (*modern_read32)(struct virtio_hw *hw, uint32_t *addr);
> + void (*modern_write8)(struct virtio_hw *hw,
> + uint8_t *addr, uint8_t val);
> + void (*modern_write16)(struct virtio_hw *hw,
> + uint16_t *addr, uint16_t val);
> + void (*modern_write32)(struct virtio_hw *hw,
> + uint32_t *addr, uint32_t val);
One thing about abstraction is that you need define one set of operations,
instead of two similar sets. Thus, you need define following operations
only:
- read8
- read16
- read32
- write8
- write16
- write32
And make a proper assignment after the modern/legacy detection.
> +
> + int (*map_pci_cfg)(struct virtio_hw *hw);
> + void (*unmap_pci_cfg)(struct virtio_hw *hw);
> + void *(*get_cfg_addr)(struct virtio_hw *hw,
> + struct virtio_pci_cap *cap);
> + int (*read_pci_cfg)(struct virtio_hw *hw,
> + void *buf, size_t len, off_t offset);
It'd be good if you can post the patches that use above abstract
operations, so that people can tell if they are properly defined.
--yliu
[dpdk-dev] [dpdk-users] Broken hash table functions with CFLAGS -O3
> -Original Message- > From: users [mailto:users-bounces at dpdk.org] On Behalf Of Dmitriy Yakovlev > Sent: Friday, January 15, 2016 1:20 AM > To: users at dpdk.org > Subject: [dpdk-users] Broken hash table functions with CFLAGS -O3 > > Hello. > I trying to use hash tables for adding struct ip:port as key. > When trying to add duplicated key it's successfuly added second time, not > always, but sometimes. > Please see this youtube video, where I'm demonstrating this bug: > https://www.youtube.com/watch?v=vsXVxISpmnU > Code on github: https://github.com/BombermaG/bug-app > > When using CFLAGS -O2 this problem cannot be repeated. > It's problem with -O3 flag and I must use O2 or how can I solve it? > Thank you for helping. > (Sorry if this message double posting). > > Spec info. Tell me, if you need more info. > dpdk 2.2.0 Hello Dmitriy, Thanks for the detailed report. I am able to reproduce the issue with gcc 4.7 and 4.8. The problem is that the signature sometimes changes, due to a different key and therefore the bucket where it should be stored is the wrong one. Actually, the hash table is fine. The issue is that your key is a structure of a 4-byte and 2-byte integers, so your key size should be 6, but instead, it is 8, because sizeof(struct...) includes padding to have it multiple of 4. Most times, that padding is 0, so it is fine, but when that padding is not 0, the key is different and then it looks like you are adding a duplicate (but actually you are adding a different key!). So, either add padding manually in the key or manually set the key size to 6. Regards, Pablo > > Linux 3.10.0-229.el7.x86_64 #1 SMP Fri Mar 6 11:36:42 UTC 2015 x86_64 > x86_64 x86_64 GNU/Linux > > gcc -v > Using built-in specs. > COLLECT_GCC=gcc > COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.5/lto-wrapper > Target: x86_64-redhat-linux > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man -- > infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla > --enable-bootstrap --enable-shared --enable-threads=posix --enable- > checking=release --with-system-zlib --enable-__cxa_atexit --disable- > libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id - > -with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj- > c++,java,fortran,ada,go,lto > --enable-plugin --enable-initfini-array --disable-libgcj --with- > isl=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/isl- > install > --with-cloog=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat- > linux/cloog-install > --enable-gnu-indirect-function --with-tune=generic --with-arch_32=x86-64 - > -build=x86_64-redhat-linux Thread model: posix gcc version 4.8.5 20150623 > (Red Hat 4.8.5-4) (GCC) > > Intel(R) Xeon(R) CPU E5-2643 v2 @ 3.50GHz
[dpdk-dev] [dpdk-users] Broken hash table functions with CFLAGS -O3
Wrong list, sorry > -Original Message- > From: De Lara Guarch, Pablo > Sent: Monday, January 18, 2016 1:48 PM > To: bombermag at gmail.com > Cc: dev at dpdk.org; De Lara Guarch, Pablo > Subject: RE: [dpdk-users] Broken hash table functions with CFLAGS -O3 > > > -Original Message- > > From: users [mailto:users-bounces at dpdk.org] On Behalf Of Dmitriy > Yakovlev > > Sent: Friday, January 15, 2016 1:20 AM > > To: users at dpdk.org > > Subject: [dpdk-users] Broken hash table functions with CFLAGS -O3 > > > > Hello. > > I trying to use hash tables for adding struct ip:port as key. > > When trying to add duplicated key it's successfuly added second time, not > > always, but sometimes. > > Please see this youtube video, where I'm demonstrating this bug: > > https://www.youtube.com/watch?v=vsXVxISpmnU > > Code on github: https://github.com/BombermaG/bug-app > > > > When using CFLAGS -O2 this problem cannot be repeated. > > It's problem with -O3 flag and I must use O2 or how can I solve it? > > Thank you for helping. > > (Sorry if this message double posting). > > > > Spec info. Tell me, if you need more info. > > dpdk 2.2.0 > > Hello Dmitriy, > > Thanks for the detailed report. I am able to reproduce the issue with > gcc 4.7 and 4.8. The problem is that the signature sometimes changes, > due to a different key and therefore the bucket where it should be stored > is the wrong one. > > Actually, the hash table is fine. The issue is that your key is a structure > of a 4-byte and 2-byte integers, so your key size should be 6, but instead, > it is 8, because sizeof(struct...) includes padding to have it multiple of 4. > Most times, that padding is 0, so it is fine, but when that padding is not 0, > the key is different and then it looks like you are adding a duplicate > (but actually you are adding a different key!). > So, either add padding manually in the key or manually set the key size to 6. > > Regards, > Pablo > > > > Linux 3.10.0-229.el7.x86_64 #1 SMP Fri Mar 6 11:36:42 UTC 2015 x86_64 > > x86_64 x86_64 GNU/Linux > > > > gcc -v > > Using built-in specs. > > COLLECT_GCC=gcc > > COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.5/lto- > wrapper > > Target: x86_64-redhat-linux > > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man -- > > infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla > > --enable-bootstrap --enable-shared --enable-threads=posix --enable- > > checking=release --with-system-zlib --enable-__cxa_atexit --disable- > > libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id - > > -with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj- > > c++,java,fortran,ada,go,lto > > --enable-plugin --enable-initfini-array --disable-libgcj --with- > > isl=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/isl- > > install > > --with-cloog=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat- > > linux/cloog-install > > --enable-gnu-indirect-function --with-tune=generic --with-arch_32=x86-64 - > > -build=x86_64-redhat-linux Thread model: posix gcc version 4.8.5 20150623 > > (Red Hat 4.8.5-4) (GCC) > > > > Intel(R) Xeon(R) CPU E5-2643 v2 @ 3.50GHz
[dpdk-dev] [PATCH v5 1/2] tools: Add support for handling built-in kernel modules
Hi Kamil,
First of all, sorry for no one has reviewed your patches for over one
month! You may want to ping more often (say, per week) next time if it
still happenes :)
Another thing is that there is no maintainer for tools code.
On Wed, Dec 09, 2015 at 02:19:57PM +0100, Kamil Rytarowski wrote:
> Currently dpdk_nic_bind.py detects Linux kernel modules via reading
> /proc/modules. Built-in ones aren't listed there and therefore they are not
> being found by the script.
>
> Add support for checking built-in modules with parsing the sysfs files.
>
> This commit obsoletes the /proc/modules parsing approach.
>
> Signed-off-by: Kamil Rytarowski
> Signed-off-by: David Marchand
> ---
> tools/dpdk_nic_bind.py | 27 +--
> 1 file changed, 17 insertions(+), 10 deletions(-)
>
> diff --git a/tools/dpdk_nic_bind.py b/tools/dpdk_nic_bind.py
> index f02454e..e161062 100755
> --- a/tools/dpdk_nic_bind.py
> +++ b/tools/dpdk_nic_bind.py
> @@ -156,22 +156,29 @@ def check_modules():
> '''Checks that igb_uio is loaded'''
> global dpdk_drivers
>
> -fd = file("/proc/modules")
> -loaded_mods = fd.readlines()
> -fd.close()
> -
> # list of supported modules
> mods = [{"Name" : driver, "Found" : False} for driver in dpdk_drivers]
>
> # first check if module is loaded
> -for line in loaded_mods:
> +try:
> +# Get list of syfs modules, some of them might be builtin and merge
> with mods
> +sysfs_path = '/sys/module/'
> +
> +# Get the list of directories in sysfs_path
> +sysfs_mods = [os.path.join(sysfs_path,o) for o in
> os.listdir(sysfs_path) if os.path.isdir(os.path.join(sysfs_path,o))]
Minor nit: it's quite a long line; you may need break it. And space is
needed after ','.
Otherwise, this patch looks good to me.
--yliu
[dpdk-dev] [PATCH v5 2/2] eal/linux: Add support for handling built-in kernel modules
On Wed, Dec 09, 2015 at 02:19:58PM +0100, Kamil Rytarowski wrote: > Currently rte_eal_check_module() detects Linux kernel modules via reading > /proc/modules. Built-in ones aren't listed there and therefore they are not > being found by the script. > > Add support for checking built-in modules with parsing the sysfs files > > This commit obsoletes the /proc/modules parsing approach. > > Signed-off-by: Kamil Rytarowski > Signed-off-by: David Marchand Acked-by: Yuanhan Liu Thanks. --yliu
[dpdk-dev] [RFC] cryptodev: Change burst APIs to crypto operation oriented
Hi Declan, On 01/12/2016 07:11 PM, Declan Doherty wrote: > In this rfc I'm looking to get some feedback on a proposal to change the > cryptodev burst API from the current implementation of accepting burst > of rte_mbuf's to a burst API based on rte_crypto_op's. > > -static inline uint16_t > -rte_cryptodev_dequeue_burst(uint8_t dev_id, uint16_t qp_id, > - struct rte_mbuf **pkts, uint16_t nb_pkts) > +static inline uint16_t > +rte_cryptodev_dequeue_op_burst(uint8_t dev_id, uint16_t qp_id, > + struct rte_crypto_op **ops, uint16_t nb_ops) > > > -static inline uint16_t > -rte_cryptodev_dequeue_burst(uint8_t dev_id, uint16_t qp_id, > - struct rte_mbuf **pkts, uint16_t nb_pkts) > + static inline uint16_t > +rte_cryptodev_dequeue_op_burst(uint8_t dev_id, uint16_t qp_id, > + struct rte_crypto_op **ops, uint16_t nb_ops) > > > [...] > > Regarding the rte_mbuf_offload library I think that it should be removed > and that we can look adding a more general solution for managing > external metadata to the rte_mbuf library when that functionality is > required. This looks fine to me. Thanks, Olivier
[dpdk-dev] [PATCH v5 1/2] tools: Add support for handling built-in kernel modules
Hi Kamil, 2015-12-09 14:19, Kamil Rytarowski: > Currently dpdk_nic_bind.py detects Linux kernel modules via reading > /proc/modules. Built-in ones aren't listed there and therefore they are not > being found by the script. > > Add support for checking built-in modules with parsing the sysfs files. > > This commit obsoletes the /proc/modules parsing approach. > > Signed-off-by: Kamil Rytarowski I have a doubt about this tag: > Signed-off-by: David Marchand What do you mean here?
[dpdk-dev] [PATCH v2 1/3] cmdline: increase command line buffer
Hi,
On 01/15/2016 10:00 AM, Panu Matilainen wrote:
diff --git a/lib/librte_cmdline/cmdline_rdline.h
b/lib/librte_cmdline/cmdline_rdline.h
index b9aad9b..72e2dad 100644
--- a/lib/librte_cmdline/cmdline_rdline.h
+++ b/lib/librte_cmdline/cmdline_rdline.h
@@ -93,7 +93,7 @@ extern "C" {
#endif
/* configuration */
-#define RDLINE_BUF_SIZE 256
+#define RDLINE_BUF_SIZE 512
#define RDLINE_PROMPT_SIZE 32
#define RDLINE_VT100_BUF_SIZE 8
#define RDLINE_HISTORY_BUF_SIZE BUFSIZ
>>>
>>> Having to break a library ABI for a change like this is a bit
>>> ridiculous.
>>
>> Sure, but John McNamara needed it to handle flow director with IPv6[1].
>>
>> For my part, I was needing it to manipulate the RETA table, but as I
>> wrote in the cover letter, it ends by breaking other commands.
>> Olivier Matz, has proposed another way to handle long commands lines[2],
>> it could be a good idea to go on this direction.
>>
>> For RETA situation, we already discussed on a new API, but for now, I
>> do not have time for it (and as it is another ABI breakage it could only
>> be done for 16.07 or 2.4)[3].
>>
>> If this patch is no more needed we can just drop it, for that I would
>> like to have the point of view from John.
>
> Note that I was not objecting to the patch as such, I can easily see 256
> characters not being enough for commandline buffer.
>
> I was merely noting that having to break an ABI to increase an
> effectively internal buffer size is a sign of a, um, less-than-optimal
> library design.
You are right about the cmdline ABI. Changing this buffer size
should not imply an ABI change. I'll try to find some time to
investigate this issue.
Another question we could raise is: should we export the API of
librte_cmdline to external applications? Now that baremetal dpdk is
not supported, having this library in dpdk is probably useless as
we can surely find standard replacements for it. A first step could
be to mark it as "internal".
About the patch N?lio's patch itself, I'm not so convinced having more
than 256 characters is absolutely required, and I would prefer to see
the commands beeing reworked to be more human-readable. On the other
hand, the ABI breakage was announced so there is no reason to nack
this patch now.
Regards,
Olivier
[dpdk-dev] [PATCH] mk: Fix examples install
Hi, Since there was neither positive nor negative feedback so far I wanted to ask if this patch is ok? Especially since we had a discussion on the approach I chose in the first approach to this issue I'd be happy about a ack/nak. Kind Regards, Christian Christian Ehrhardt Software Engineer, Ubuntu Server Canonical Ltd On Fri, Jan 8, 2016 at 12:08 PM, Christian Ehrhardt < christian.ehrhardt at canonical.com> wrote: > Forgot to mention, an easy way to test-trigger this e.g. on the dpdk 2.2 > tarball. > > make clean; make config T=x86_64-native-linuxapp-gcc && && make -j && make > V=1 DESTDIR=Test install-doc > > In this example the install-doc fails with this: > [...] > Build complete [x86_64-native-linuxapp-gcc] > make -f /home/ubuntu/dpdk-2.2.0/mk/rte.sdkinstall.mk install-doc > cp -a /home/ubuntu/dpdk-2.2.0/examples Test/usr/local/share/dpdk > cp: cannot create directory ?Test/usr/local/share/dpdk?: No such file or > directory > /home/ubuntu/dpdk-2.2.0/mk/rte.sdkinstall.mk:160: recipe for target > 'install-doc' failed > make[1]: *** [install-doc] Error 1 > /home/ubuntu/dpdk-2.2.0/mk/rte.sdkroot.mk:101: recipe for target > 'install-doc' failed > make: *** [install-doc] Error 2 > > Christian Ehrhardt > Software Engineer, Ubuntu Server > Canonical Ltd > > On Fri, Jan 8, 2016 at 12:03 PM, Christian Ehrhardt < > christian.ehrhardt at canonical.com> wrote: > >> Depending on non-doc targets being built before and the setting of DESTDIR >> the copy of the examples dir being part of install-doc could in some >> cases fail >> with a non existant "$(DESTDIR)$(datadir)" target directory. >> Add the conditional rte_mkdir for that to avoid the issue. >> >> Signed-off-by: Christian Ehrhardt >> --- >> >> [diffstat] >> rte.sdkinstall.mk |1 + >> 1 file changed, 1 insertion(+) >> >> [diff] >> diff --git a/mk/rte.sdkinstall.mk b/mk/rte.sdkinstall.mk >> index c159bf7..68e56b6 100644 >> --- a/mk/rte.sdkinstall.mk >> +++ b/mk/rte.sdkinstall.mk >> @@ -157,4 +157,5 @@ ifneq ($(wildcard $O/doc/*/*/*pdf),) >> $(Q)$(call rte_mkdir, $(DESTDIR)$(docdir)/guides) >> $(Q)cp -a $O/doc/*/*/*pdf $(DESTDIR)$(docdir)/guides >> endif >> + $(Q)$(call rte_mkdir, $(DESTDIR)$(datadir)) >> $(Q)cp -a $(RTE_SDK)/examples $(DESTDIR)$(datadir) >> > >
[dpdk-dev] Proposal for a big eal / ethdev cleanup
On 14/01/16 10:38, David Marchand wrote:
> Hello all,
>
> Here is a proposal of a big cleanup in ethdev (cryptodev would have to
> follow) and eal structures.
> This is something I wanted to do for quite some time and the arrival of
> a new bus makes me think we need it.
>
> This is an alternative to what Jan proposed [1].
>
> ABI is most likely broken with this, but I think this discussion can come
> later.
>
>
> First some context on how dpdk is initialized at the moment :
>
> Let's imagine a system with one ixgbe pci device and take some
> part of ixgbe driver as an example.
>
> static struct eth_driver rte_ixgbe_pmd = {
> .pci_drv = {
> .name = "rte_ixgbe_pmd",
> .id_table = pci_id_ixgbe_map,
> .drv_flags = RTE_PCI_DRV_NEED_MAPPING |
> RTE_PCI_DRV_INTR_LSC | RTE_PCI_DRV_DETACHABLE,
> },
> .eth_dev_init = eth_ixgbe_dev_init,
> .eth_dev_uninit = eth_ixgbe_dev_uninit,
> .dev_private_size = sizeof(struct ixgbe_adapter),
> };
>
> static int
> rte_ixgbe_pmd_init(const char *name __rte_unused, const char *params
> __rte_unused)
> {
> PMD_INIT_FUNC_TRACE();
> rte_eth_driver_register(&rte_ixgbe_pmd);
> return 0;
> }
>
> static struct rte_driver rte_ixgbe_driver = {
> .type = PMD_PDEV,
> .init = rte_ixgbe_pmd_init,
> };
>
> PMD_REGISTER_DRIVER(rte_ixgbe_driver)
>
>
> DPDK initialisation goes as follows (focusing on ixgbe driver):
>
> PMD_REGISTER_DRIVER(rte_ixgbe_driver) which adds it to dev_driver_list
>
> rte_eal_init()
> -> rte_eal_pci_init()
>-> rte_eal_pci_scan() which fills pci_device_list
>
> -> rte_eal_dev_init()
>-> for each rte_driver (first vdev, then pdev), call driver->init()
> so here rte_ixgbe_pmd_init(NULL, NULL)
> -> rte_eth_driver_register(&rte_ixgbe_pmd);
> -> fills rte_ixgbe_pmd.pci_drv.devinit = rte_eth_dev_init
> -> call rte_eal_pci_register() which adds it to pci_driver_list
>
> -> rte_eal_pci_probe()
>-> for each rte_pci_device found in rte_eal_pci_scan(), and for all
> rte_pci_driver registered, call devinit(dr, dev),
> so here rte_eth_dev_init(dr, dev)
> -> creates a new eth_dev (which is a rte_eth_dev), then adds
>reference to passed dev pointer (which is a rte_pci_device), to
>passed dr pointer (which is a rte_pci_driver cast as a eth_driver)
> -> call eth_drv->eth_dev_init(eth_dev)
>so here eth_ixgbe_dev_init(eth_dev)
> -> fills other parts of eth_dev
> -> rte_eth_copy_pci_info(eth_dev, pci_dev)
>
>
> By the way, when invoking ethdev init, the pci-specific stuff is only
> handled in functions called from the drivers themselves, which already
> know that they are dealing with pci resources.
>
>
> Later in the life of the application, ethdev api is called for hotplug.
>
> int rte_eth_dev_attach(const char *devargs, uint8_t *port_id);
>
> A devargs is used to identify a vdev/pdev driver and call it to create a
> new rte_eth_dev.
> Current code goes as far as parsing devargs to understand if this is a
> pci device or a vdev.
> This part should be moved to eal since this is where all the "bus" logic
> is.
>
>
>
> So now, what I had in mind is something like this.
> It is far from perfect and I certainly did some shortcuts in my
> reasoning.
>
>
> Generic device/driver
>
> - introduce a rte_device structure,
> - a rte_device has a name, that identifies it in a unique way across
> all buses, maybe something like pci::00:01.0, and for vdev,
> vdev:name
> - a rte_device references a rte_driver,
> - a rte_device references devargs
> - a rte_device embeds a intr_handle
> - rte_device objects are created by "buses"
> - a function to retrieve rte_device objects based on name is added
>
> - current rte_driver does not need to know about the pmd_type
> (pdev/vdev), this is only a way to order drivers init in eal, we could
> use the rte_driver names to order them or maybe remove this ordering
> - init and uninit functions are changed to take a pointer to a
> rte_device
>
> rte_device and rte_driver structures are at the "bus" level.
> Those are the basic structures we will build the other objects on.
>
>
> Impact on PCI device/driver
>
> - rte_pci_device is modified to embed a rte_device (embedding makes it
> possible later to cast the rte_device and get the rte_pci_device in pci
> specific functions)
> - no need for a rte_pci_driver reference in rte_pci_device, since we
> have the rte_device driver
>
> - rte_pci_driver is modified to embed a rte_driver
> - no more devinit and devuninit functions in rte_pci_driver, they can
> be moved as init / uninit functions in rte_driver
>
> - pci scan code creates rte_pci_device objects, associates them to
> rte_pci_driver, fills the driver field of the rte_driver then pass
> them to rte_driver init function.
>
> rte_pci_device and rte_pci_driver are specific implementation of
> rte_device and rte_driver.
> There are there to
[dpdk-dev] Fw: Proposal for a big eal / ethdev cleanup
I've lost some To/CC in the e-mail, so forwarding to dpdk-dev... Begin forwarded message: Date: Mon, 18 Jan 2016 15:58:34 +0100 From: Jan Viktorin To: David Marchand Subject: Re: Proposal for a big eal / ethdev cleanup Hello David, I am playing around a little bit with the code according to your ideas. I found quite a wierd situation with the rte_driver which makes the transition to a better infrastructure very difficult from my point of view... On Thu, 14 Jan 2016 11:38:16 +0100 David Marchand wrote: > Impact on PCI device/driver > > - rte_pci_device is modified to embed a rte_device (embedding makes it > possible later to cast the rte_device and get the rte_pci_device in pci > specific functions) This is OK and it can be done quite easily. > - no need for a rte_pci_driver reference in rte_pci_device, since we > have the rte_device driver This is an issue, see below. > > - rte_pci_driver is modified to embed a rte_driver The rte_driver and rte_pci_driver are related in a much different way at the moment. The meaning of rte_driver is more like an rte_module in the current DPDK. In fact, we don't have any generic rte_driver suitable for this purpose. Thus, the transition to this model needs to rename rte_driver to rte_module and to introduce a new data structure named rte_driver. Quite confusing... but this is how I understand it. (What is the current relation between rte_pci_device and rte_pci_driver? Is the rte_pci_driver a singleton? I doubt. Well, it cannot be, as it is embedded in each eth_driver.) Another way, not that beautiful... Introduce rte_generic_driver and rte_generic_device. (Or rte_gen_driver/rte_gen_device or rte_bus_driver/rte_bus_device if you want). This enables to let the rte_driver as it is and it avoids a lot of quite terrible transition patches that can break everything. > - no more devinit and devuninit functions in rte_pci_driver, they can > be moved as init / uninit functions in rte_driver The rte_driver has init/uninit already and its semantics seem to be module_init and module_uninit. Regards Jan -- Jan Viktorin E-mail: Viktorin at RehiveTech.com System Architect Web:www.RehiveTech.com RehiveTech Brno, Czech Republic
[dpdk-dev] Proposal for a big eal / ethdev cleanup
Hello Declan, On Mon, Jan 18, 2016 at 3:54 PM, Declan Doherty wrote: > In your proposal above, having an bus type enumeration in the rte_device > which specifies the bus type might be simpler than having to parse a > specific name formatting. This is not simpler. This is useless afaics. "upper" / "functional" layer should not rely on the "lower" / "physical" layer information. Your crypto device should be described through a struct with crypto ops functions. When registering the device, the (whatever bus) driver should register a crypto device with its own crypto ops. The only place I can think of, where parsing a resource name would have an interest, is when crossing borders dpdk <-> user application. This is why I proposed a naming convention to identify the devices. > One thing that we are working on at the moment and it will affect your > proposed solution above quite a lot is the ability to support devices with > share-able buses in DPDK, we will have a RFC for this proposal in the next > few days but I'll give a quick overview now. The Quick Assist device which > we currently support a symmetric crypto cryptodev PMD for in DPDK is a > mufti-function device, in that it supports symmetric and asymmetric crypto > and compression functionality. These features are supported from a single > device instance through different hardware queues. We want to provide each > service through as a separate dpdk device but with and underlying shared bus > (in our case PCI), this way a device/queue will only provide 1 service type. > What we are going to propose is to allow a rte_pci_device to be shared my > multiple pdevs, to do this we would register multiple drivers against the > same pci_id and with a small modification to the EAL > rte_eal_pci_probe_all()/ rte_eal_pci_probe() functions we create a device > instance for each matched driver as long as the diver has a share-able flag. >From the description you give, it sounds to me you want to expose two crypto devices that share the same pci device but I can't see where my proposed solution can not work. eal finds one pci device, associates it to one pci driver which then creates two different crypto devices (with their own specific logic). Those crypto devices references a generic rte_device (which happens to be a pci device) referencing a generic rte_driver. So to me, this is pure specific driver/crypto stuff, nothing to do in eal. What did I miss ? Regards, -- David Marchand
[dpdk-dev] Proposal for a big eal / ethdev cleanup
2016-01-16 16:53, David Marchand: > On Thu, Jan 14, 2016 at 12:46 PM, Jan Viktorin > wrote: > > On Thu, 14 Jan 2016 11:38:16 +0100 > > David Marchand wrote: > >> Here is a proposal of a big cleanup in ethdev (cryptodev would have to > >> follow) and eal structures. [...] > >> ABI is most likely broken with this, but I think this discussion can come > >> later. > > > > I was trying in my initial approach to stay as much API and ABI backwards > > compatible as possible to be acceptable into upstream. As just a few > > people have shown their interest in these changes, I consider the ABI > > compatibility very important. > > > > I can see, that your approach does not care too much... Otherwise, it looks > > good to me. It is closer to the Linux drivers infra, so it seems to be > > clearer > > then the current one. > > I did this on purpose. > From my point of view, we will have an API/ABI breakage in this code > at one point. > So I sent this mail to show where I'd like us to go, because this > looks saner on the mid/long term. [...] > > Another point is that the ethdev infra should not know about the > > underlying bus infra. The question is whether we do a big clean > > up (extract PCI-bus code out) or a small clean up (give the ethdev > > infra a hint which bus system it deals with). > > Yes, and I think these two choices are reflected by our two respective > proposals :-) Regarding the API/ABI breaks and how the big the changes must be, I'd say it is nice to have some changes without breaking the user interfaces. Though sometimes there is a great value to refactor things and break them. In such case, it is better to do the big changes at once so the breaking would impact only one version instead of breaking the same API again and again. About this proposal, I vote for: +1 [...] > > Moreover, there is no way how to pass arguments to pdevs, only to > > vdevs. This was shortly disscussed in [2] for the szedata2 PMD. > > > > [2] http://dpdk.org/ml/archives/dev/2015-October/026285.html > > Shorty discussed with Thomas, yes. > But after some experiments, it appears that you can pass devargs after > a whitelist option at init (--pci-whitelist > :xx:xx.x,whataniceoptionwehavehere=1). > This does not work for hotplug. > This is undocumented and this looks like a workaround, so I would > prefer we come up with a better api for 2.3. Yes we need also to redefine the command line syntax to have a generic way of passing per-device parameters to the drivers.
[dpdk-dev] [RFC 0/6] Preview of a big eal/ethdev cleanup
Hello, based on the recent discussions [1], I have prepared a little preview of patches reflecting the basic ideas. That is: * generalization of device and driver structures * embedding a generic device and driver structure in the bus-specific ones * moving some members from PCI-specific structures to the generic ones * introduction of the container_of macro The code compiles for x86_64/linux/gcc, however, I didn't try any runtime yet. [1] http://dpdk.org/ml/archives/dev/2016-January/031390.html Regards Jan --- Jan Viktorin (6): eal: introduce rte_bus_device and rte_bus_driver eal: define macro container_of eal: move devargs from rte_pci_device to rte_device eal: move numa_node from rte_pci_device to rte_device eal: move intr_handle from rte_pci_device to rte_device eal: move driver pointer from rte_pci_device to rte_bus_device app/test/virtual_pmd.c | 4 +-- drivers/net/e1000/em_ethdev.c | 14 +- drivers/net/e1000/igb_ethdev.c | 24 - drivers/net/enic/enic_main.c | 4 +-- drivers/net/fm10k/fm10k_ethdev.c | 16 ++-- drivers/net/i40e/i40e_ethdev.c | 32 +++ drivers/net/i40e/i40e_ethdev_vf.c | 16 ++-- drivers/net/ixgbe/ixgbe_ethdev.c | 28 ++-- drivers/net/virtio/virtio_ethdev.c | 41 ++ lib/librte_cryptodev/rte_cryptodev.c | 3 ++- lib/librte_eal/bsdapp/eal/eal_pci.c| 16 ++-- lib/librte_eal/common/eal_common_pci.c | 14 +- lib/librte_eal/common/eal_common_pci_uio.c | 18 ++--- lib/librte_eal/common/include/rte_common.h | 16 lib/librte_eal/common/include/rte_dev.h| 15 +++ lib/librte_eal/common/include/rte_pci.h| 10 +--- lib/librte_eal/linuxapp/eal/eal_pci.c | 8 +++--- lib/librte_eal/linuxapp/eal/eal_pci_uio.c | 28 ++-- lib/librte_eal/linuxapp/eal/eal_pci_vfio.c | 14 +- lib/librte_ether/rte_ethdev.c | 16 +++- 20 files changed, 191 insertions(+), 146 deletions(-) -- 2.7.0
[dpdk-dev] [RFC 1/6] eal: introduce rte_bus_device and rte_bus_driver
Define a general represenation of a device and driver in DPDK. The goal is to
get rid of the deep dependency on the PCI. Higher level code should not
reference the bus-specific structures as it does not need to.
PCI infrastructure embeds those structures. Other infrastructures will do the
same.
Suggested-by: David Marchand
Signed-off-by: Jan Viktorin
---
lib/librte_eal/common/include/rte_dev.h | 9 +
lib/librte_eal/common/include/rte_pci.h | 3 +++
2 files changed, 12 insertions(+)
diff --git a/lib/librte_eal/common/include/rte_dev.h
b/lib/librte_eal/common/include/rte_dev.h
index f1b5507..b779705 100644
--- a/lib/librte_eal/common/include/rte_dev.h
+++ b/lib/librte_eal/common/include/rte_dev.h
@@ -50,6 +50,7 @@ extern "C" {
#include
#include
+#include
__attribute__((format(printf, 2, 0)))
static inline void
@@ -151,6 +152,14 @@ void rte_eal_driver_register(struct rte_driver *driver);
*/
void rte_eal_driver_unregister(struct rte_driver *driver);
+struct rte_bus_driver {
+ const char *name;
+};
+
+struct rte_bus_device {
+ const char *name;
+};
+
/**
* Initalize all the registered drivers in this process
*/
diff --git a/lib/librte_eal/common/include/rte_pci.h
b/lib/librte_eal/common/include/rte_pci.h
index 334c12e..10a2306 100644
--- a/lib/librte_eal/common/include/rte_pci.h
+++ b/lib/librte_eal/common/include/rte_pci.h
@@ -83,6 +83,7 @@ extern "C" {
#include
#include
+#include
TAILQ_HEAD(pci_device_list, rte_pci_device); /**< PCI devices in D-linked Q. */
TAILQ_HEAD(pci_driver_list, rte_pci_driver); /**< PCI drivers in D-linked Q. */
@@ -166,6 +167,7 @@ struct rte_pci_device {
int numa_node; /**< NUMA node connection */
struct rte_devargs *devargs;/**< Device user arguments */
enum rte_kernel_driver kdrv;/**< Kernel driver passthrough
*/
+ struct rte_bus_device dev; /**< Generic device */
};
/** Any PCI device identifier (vendor, device, ...) */
@@ -209,6 +211,7 @@ struct rte_pci_driver {
pci_devuninit_t *devuninit; /**< Device uninit function. */
const struct rte_pci_id *id_table; /**< ID table, NULL terminated.
*/
uint32_t drv_flags; /**< Flags contolling handling
of device. */
+ struct rte_bus_driver drv; /**< Generic driver */
};
/** Device needs PCI BAR mapping (done with either IGB_UIO or VFIO) */
--
2.7.0
[dpdk-dev] [RFC 2/6] eal: define macro container_of
Signed-off-by: Jan Viktorin
---
lib/librte_eal/common/include/rte_common.h | 16
1 file changed, 16 insertions(+)
diff --git a/lib/librte_eal/common/include/rte_common.h
b/lib/librte_eal/common/include/rte_common.h
index b58a384..bf6560d 100644
--- a/lib/librte_eal/common/include/rte_common.h
+++ b/lib/librte_eal/common/include/rte_common.h
@@ -322,6 +322,22 @@ rte_bsf32(uint32_t v)
#define offsetof(TYPE, MEMBER) __builtin_offsetof (TYPE, MEMBER)
#endif
+/**
+ * Return pointer to the wrapping struct instance.
+ * Example:
+ *
+ * struct wrapper {
+ * ...
+ * struct child c;
+ * ...
+ * };
+ *
+ * struct child *x = obtain(...);
+ * struct wrapper *w = container_of(x, struct wrapper, c);
+ */
+#define container_of(p, type, member) \
+ ((type *) (((char *) (p)) - offsetof(type, member)))
+
#define _RTE_STR(x) #x
/** Take a macro value and get a string version of it */
#define RTE_STR(x) _RTE_STR(x)
--
2.7.0
[dpdk-dev] [RFC 3/6] eal: move devargs from rte_pci_device to rte_device
Suggested-by: David Marchand
Signed-off-by: Jan Viktorin
---
lib/librte_eal/common/eal_common_pci.c | 6 +++---
lib/librte_eal/common/include/rte_dev.h | 3 +++
lib/librte_eal/common/include/rte_pci.h | 1 -
3 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/lib/librte_eal/common/eal_common_pci.c
b/lib/librte_eal/common/eal_common_pci.c
index dcfe947..60501a5 100644
--- a/lib/librte_eal/common/eal_common_pci.c
+++ b/lib/librte_eal/common/eal_common_pci.c
@@ -173,8 +173,8 @@ rte_eal_pci_probe_one_driver(struct rte_pci_driver *dr,
struct rte_pci_device *d
dev->id.device_id, dr->name);
/* no initialization when blacklisted, return without error */
- if (dev->devargs != NULL &&
- dev->devargs->type == RTE_DEVTYPE_BLACKLISTED_PCI) {
+ if (dev->dev.devargs != NULL &&
+ dev->dev.devargs->type == RTE_DEVTYPE_BLACKLISTED_PCI) {
RTE_LOG(DEBUG, EAL, " Device is blacklisted, not
initializing\n");
return 1;
}
@@ -401,7 +401,7 @@ rte_eal_pci_probe(void)
/* set devargs in PCI structure */
devargs = pci_devargs_lookup(dev);
if (devargs != NULL)
- dev->devargs = devargs;
+ dev->dev.devargs = devargs;
/* probe all or only whitelisted devices */
if (probe_all)
diff --git a/lib/librte_eal/common/include/rte_dev.h
b/lib/librte_eal/common/include/rte_dev.h
index b779705..1ab47f9 100644
--- a/lib/librte_eal/common/include/rte_dev.h
+++ b/lib/librte_eal/common/include/rte_dev.h
@@ -156,8 +156,11 @@ struct rte_bus_driver {
const char *name;
};
+struct rte_devargs;
+
struct rte_bus_device {
const char *name;
+ struct rte_devargs *devargs;
};
/**
diff --git a/lib/librte_eal/common/include/rte_pci.h
b/lib/librte_eal/common/include/rte_pci.h
index 10a2306..b894913 100644
--- a/lib/librte_eal/common/include/rte_pci.h
+++ b/lib/librte_eal/common/include/rte_pci.h
@@ -165,7 +165,6 @@ struct rte_pci_device {
struct rte_pci_driver *driver; /**< Associated driver */
uint16_t max_vfs; /**< sriov enable if not zero */
int numa_node; /**< NUMA node connection */
- struct rte_devargs *devargs;/**< Device user arguments */
enum rte_kernel_driver kdrv;/**< Kernel driver passthrough
*/
struct rte_bus_device dev; /**< Generic device */
};
--
2.7.0
[dpdk-dev] [RFC 4/6] eal: move numa_node from rte_pci_device to rte_device
Signed-off-by: Jan Viktorin
---
app/test/virtual_pmd.c | 2 +-
lib/librte_eal/bsdapp/eal/eal_pci.c | 2 +-
lib/librte_eal/common/eal_common_pci.c | 4 ++--
lib/librte_eal/common/include/rte_dev.h | 1 +
lib/librte_eal/common/include/rte_pci.h | 1 -
lib/librte_eal/linuxapp/eal/eal_pci.c | 4 ++--
lib/librte_ether/rte_ethdev.c | 2 +-
7 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/app/test/virtual_pmd.c b/app/test/virtual_pmd.c
index a538c8a..0fe957f 100644
--- a/app/test/virtual_pmd.c
+++ b/app/test/virtual_pmd.c
@@ -585,7 +585,7 @@ virtual_ethdev_create(const char *name, struct ether_addr
*mac_addr,
if (eth_dev == NULL)
goto err;
- pci_dev->numa_node = socket_id;
+ pci_dev->dev.numa_node = socket_id;
pci_drv->name = virtual_ethdev_driver_name;
pci_drv->id_table = id_table;
diff --git a/lib/librte_eal/bsdapp/eal/eal_pci.c
b/lib/librte_eal/bsdapp/eal/eal_pci.c
index 6c21fbd..07fd6c8 100644
--- a/lib/librte_eal/bsdapp/eal/eal_pci.c
+++ b/lib/librte_eal/bsdapp/eal/eal_pci.c
@@ -277,7 +277,7 @@ pci_scan_one(int dev_pci_fd, struct pci_conf *conf)
dev->max_vfs = 0;
/* FreeBSD has no NUMA support (yet) */
- dev->numa_node = 0;
+ dev->dev.numa_node = 0;
/* FreeBSD has only one pass through driver */
dev->kdrv = RTE_KDRV_NIC_UIO;
diff --git a/lib/librte_eal/common/eal_common_pci.c
b/lib/librte_eal/common/eal_common_pci.c
index 60501a5..4ac180d 100644
--- a/lib/librte_eal/common/eal_common_pci.c
+++ b/lib/librte_eal/common/eal_common_pci.c
@@ -167,7 +167,7 @@ rte_eal_pci_probe_one_driver(struct rte_pci_driver *dr,
struct rte_pci_device *d
RTE_LOG(DEBUG, EAL, "PCI device "PCI_PRI_FMT" on NUMA socket
%i\n",
loc->domain, loc->bus, loc->devid,
loc->function,
- dev->numa_node);
+ dev->dev.numa_node);
RTE_LOG(DEBUG, EAL, " probe driver: %x:%x %s\n",
dev->id.vendor_id,
dev->id.device_id, dr->name);
@@ -241,7 +241,7 @@ rte_eal_pci_detach_dev(struct rte_pci_driver *dr,
RTE_LOG(DEBUG, EAL, "PCI device "PCI_PRI_FMT" on NUMA socket
%i\n",
loc->domain, loc->bus, loc->devid,
- loc->function, dev->numa_node);
+ loc->function, dev->dev.numa_node);
RTE_LOG(DEBUG, EAL, " remove driver: %x:%x %s\n",
dev->id.vendor_id,
dev->id.device_id, dr->name);
diff --git a/lib/librte_eal/common/include/rte_dev.h
b/lib/librte_eal/common/include/rte_dev.h
index 1ab47f9..593ceb3 100644
--- a/lib/librte_eal/common/include/rte_dev.h
+++ b/lib/librte_eal/common/include/rte_dev.h
@@ -161,6 +161,7 @@ struct rte_devargs;
struct rte_bus_device {
const char *name;
struct rte_devargs *devargs;
+ int numa_node;
};
/**
diff --git a/lib/librte_eal/common/include/rte_pci.h
b/lib/librte_eal/common/include/rte_pci.h
index b894913..5566e3d 100644
--- a/lib/librte_eal/common/include/rte_pci.h
+++ b/lib/librte_eal/common/include/rte_pci.h
@@ -164,7 +164,6 @@ struct rte_pci_device {
struct rte_intr_handle intr_handle; /**< Interrupt handle */
struct rte_pci_driver *driver; /**< Associated driver */
uint16_t max_vfs; /**< sriov enable if not zero */
- int numa_node; /**< NUMA node connection */
enum rte_kernel_driver kdrv;/**< Kernel driver passthrough
*/
struct rte_bus_device dev; /**< Generic device */
};
diff --git a/lib/librte_eal/linuxapp/eal/eal_pci.c
b/lib/librte_eal/linuxapp/eal/eal_pci.c
index bc5b5be..c87dd37 100644
--- a/lib/librte_eal/linuxapp/eal/eal_pci.c
+++ b/lib/librte_eal/linuxapp/eal/eal_pci.c
@@ -326,13 +326,13 @@ pci_scan_one(const char *dirname, uint16_t domain,
uint8_t bus,
dirname);
if (access(filename, R_OK) != 0) {
/* if no NUMA support, set default to 0 */
- dev->numa_node = 0;
+ dev->dev.numa_node = 0;
} else {
if (eal_parse_sysfs_value(filename, &tmp) < 0) {
free(dev);
return -1;
}
- dev->numa_node = tmp;
+ dev->dev.numa_node = tmp;
}
/* parse resources */
diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index ed971b4..908997a 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -3236,6 +3236,6 @@ rte_eth_copy_pci_info(struct rte_eth_dev *eth_dev, struct
rte_pci_device *pci_de
eth_dev->data->dev_flags |= RTE_ETH_DEV_DETACHABLE;
eth_dev->data->kdrv = pci_dev->kdrv;
- eth_dev->data->numa_node = pci_dev->numa_node;
+ eth_dev-
[dpdk-dev] [RFC 5/6] eal: move intr_handle from rte_pci_device to rte_device
Suggested-by: David Marchand
Signed-off-by: Jan Viktorin
---
drivers/net/e1000/em_ethdev.c | 14 ++---
drivers/net/e1000/igb_ethdev.c | 24 +++---
drivers/net/enic/enic_main.c | 4 ++--
drivers/net/fm10k/fm10k_ethdev.c | 16 +++
drivers/net/i40e/i40e_ethdev.c | 32 +++---
drivers/net/i40e/i40e_ethdev_vf.c | 16 +++
drivers/net/ixgbe/ixgbe_ethdev.c | 28 +-
drivers/net/virtio/virtio_ethdev.c | 16 +++
lib/librte_eal/bsdapp/eal/eal_pci.c| 14 ++---
lib/librte_eal/common/eal_common_pci_uio.c | 18 -
lib/librte_eal/common/include/rte_dev.h| 1 +
lib/librte_eal/common/include/rte_pci.h| 1 -
lib/librte_eal/linuxapp/eal/eal_pci.c | 4 ++--
lib/librte_eal/linuxapp/eal/eal_pci_uio.c | 28 +-
lib/librte_eal/linuxapp/eal/eal_pci_vfio.c | 14 ++---
lib/librte_ether/rte_ethdev.c | 4 ++--
16 files changed, 117 insertions(+), 117 deletions(-)
diff --git a/drivers/net/e1000/em_ethdev.c b/drivers/net/e1000/em_ethdev.c
index 66e8993..87ed780 100644
--- a/drivers/net/e1000/em_ethdev.c
+++ b/drivers/net/e1000/em_ethdev.c
@@ -296,7 +296,7 @@ eth_em_dev_init(struct rte_eth_dev *eth_dev)
eth_dev->data->port_id, pci_dev->id.vendor_id,
pci_dev->id.device_id);
- rte_intr_callback_register(&(pci_dev->intr_handle),
+ rte_intr_callback_register(&(pci_dev->dev.intr_handle),
eth_em_interrupt_handler, (void *)eth_dev);
return (0);
@@ -327,8 +327,8 @@ eth_em_dev_uninit(struct rte_eth_dev *eth_dev)
eth_dev->data->mac_addrs = NULL;
/* disable uio intr before callback unregister */
- rte_intr_disable(&(pci_dev->intr_handle));
- rte_intr_callback_unregister(&(pci_dev->intr_handle),
+ rte_intr_disable(&(pci_dev->dev.intr_handle));
+ rte_intr_callback_unregister(&(pci_dev->dev.intr_handle),
eth_em_interrupt_handler, (void *)eth_dev);
return 0;
@@ -506,7 +506,7 @@ eth_em_start(struct rte_eth_dev *dev)
E1000_DEV_PRIVATE(dev->data->dev_private);
struct e1000_hw *hw =
E1000_DEV_PRIVATE_TO_HW(dev->data->dev_private);
- struct rte_intr_handle *intr_handle = &dev->pci_dev->intr_handle;
+ struct rte_intr_handle *intr_handle = &dev->pci_dev->dev.intr_handle;
int ret, mask;
uint32_t intr_vector = 0;
@@ -683,7 +683,7 @@ eth_em_stop(struct rte_eth_dev *dev)
{
struct rte_eth_link link;
struct e1000_hw *hw = E1000_DEV_PRIVATE_TO_HW(dev->data->dev_private);
- struct rte_intr_handle *intr_handle = &dev->pci_dev->intr_handle;
+ struct rte_intr_handle *intr_handle = &dev->pci_dev->dev.intr_handle;
em_rxq_intr_disable(hw);
em_lsc_intr_disable(hw);
@@ -945,7 +945,7 @@ eth_em_rx_queue_intr_enable(struct rte_eth_dev *dev,
__rte_unused uint16_t queue
struct e1000_hw *hw = E1000_DEV_PRIVATE_TO_HW(dev->data->dev_private);
em_rxq_intr_enable(hw);
- rte_intr_enable(&dev->pci_dev->intr_handle);
+ rte_intr_enable(&dev->pci_dev->dev.intr_handle);
return 0;
}
@@ -1482,7 +1482,7 @@ eth_em_interrupt_action(struct rte_eth_dev *dev)
return -1;
intr->flags &= ~E1000_FLAG_NEED_LINK_UPDATE;
- rte_intr_enable(&(dev->pci_dev->intr_handle));
+ rte_intr_enable(&(dev->pci_dev->dev.intr_handle));
/* set get_link_status to check register later */
hw->mac.get_link_status = 1;
diff --git a/drivers/net/e1000/igb_ethdev.c b/drivers/net/e1000/igb_ethdev.c
index d1bbcda..860bd5c 100644
--- a/drivers/net/e1000/igb_ethdev.c
+++ b/drivers/net/e1000/igb_ethdev.c
@@ -769,12 +769,12 @@ eth_igb_dev_init(struct rte_eth_dev *eth_dev)
eth_dev->data->port_id, pci_dev->id.vendor_id,
pci_dev->id.device_id);
- rte_intr_callback_register(&pci_dev->intr_handle,
+ rte_intr_callback_register(&pci_dev->dev.intr_handle,
eth_igb_interrupt_handler,
(void *)eth_dev);
/* enable uio/vfio intr/eventfd mapping */
- rte_intr_enable(&pci_dev->intr_handle);
+ rte_intr_enable(&pci_dev->dev.intr_handle);
/* enable support intr */
igb_intr_enable(eth_dev);
@@ -827,8 +827,8 @@ eth_igb_dev_uninit(struct rte_eth_dev *eth_dev)
igb_pf_host_uninit(eth_dev);
/* disable uio intr before callback unregister */
- rte_intr_disable(&(pci_dev->intr_handle));
- rte_intr_callback_unregister(&(pci_dev->intr_handle),
+ rte_intr_disable(&(pci_dev->dev.intr_handle));
+ rte_intr_callback_unregister(&(pci_dev->dev.intr_handle),
eth_igb_interrupt_handler, (void *)eth_dev);
return 0;
@
[dpdk-dev] [RFC 6/6] eal: move driver pointer from rte_pci_device to rte_bus_device
We define to_pci_driver helper macro here.
Suggested-by: David Marchand
Signed-off-by: Jan Viktorin
---
app/test/virtual_pmd.c | 2 +-
drivers/net/virtio/virtio_ethdev.c | 25 +
lib/librte_cryptodev/rte_cryptodev.c| 3 ++-
lib/librte_eal/common/eal_common_pci.c | 4 ++--
lib/librte_eal/common/include/rte_dev.h | 1 +
lib/librte_eal/common/include/rte_pci.h | 4 +++-
lib/librte_ether/rte_ethdev.c | 10 ++
7 files changed, 32 insertions(+), 17 deletions(-)
diff --git a/app/test/virtual_pmd.c b/app/test/virtual_pmd.c
index 0fe957f..c88972d 100644
--- a/app/test/virtual_pmd.c
+++ b/app/test/virtual_pmd.c
@@ -626,7 +626,7 @@ virtual_ethdev_create(const char *name, struct ether_addr
*mac_addr,
eth_dev->dev_ops = &dev_private->dev_ops;
eth_dev->pci_dev = pci_dev;
- eth_dev->pci_dev->driver = ð_drv->pci_drv;
+ eth_dev->pci_dev->dev.driver = ð_drv->pci_drv.drv;
eth_dev->rx_pkt_burst = virtual_ethdev_rx_burst_success;
eth_dev->tx_pkt_burst = virtual_ethdev_tx_burst_success;
diff --git a/drivers/net/virtio/virtio_ethdev.c
b/drivers/net/virtio/virtio_ethdev.c
index 1ee9f85..22a7849 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -487,11 +487,12 @@ virtio_dev_close(struct rte_eth_dev *dev)
{
struct virtio_hw *hw = dev->data->dev_private;
struct rte_pci_device *pci_dev = dev->pci_dev;
+ struct rte_pci_driver *pci_drv = to_pci_driver(pci_dev->dev.driver);
PMD_INIT_LOG(DEBUG, "virtio_dev_close");
/* reset the NIC */
- if (pci_dev->driver->drv_flags & RTE_PCI_DRV_INTR_LSC)
+ if (pci_drv->drv_flags & RTE_PCI_DRV_INTR_LSC)
vtpci_irq_config(hw, VIRTIO_MSI_NO_VECTOR);
vtpci_reset(hw);
hw->started = 0;
@@ -1080,6 +1081,7 @@ virtio_has_msix(const struct rte_pci_addr *loc)
/* Extract I/O port numbers from sysfs */
static int virtio_resource_init_by_uio(struct rte_pci_device *pci_dev)
{
+ struct rte_pci_driver *pci_drv = to_pci_driver(pci_dev->dev.driver);
char dirname[PATH_MAX];
char filename[PATH_MAX];
unsigned long start, size;
@@ -1122,7 +1124,7 @@ static int virtio_resource_init_by_uio(struct
rte_pci_device *pci_dev)
}
pci_dev->dev.intr_handle.type = RTE_INTR_HANDLE_UIO;
- pci_dev->driver->drv_flags |= RTE_PCI_DRV_INTR_LSC;
+ pci_drv->drv_flags |= RTE_PCI_DRV_INTR_LSC;
return 0;
}
@@ -1130,6 +1132,7 @@ static int virtio_resource_init_by_uio(struct
rte_pci_device *pci_dev)
/* Extract port I/O numbers from proc/ioports */
static int virtio_resource_init_by_ioports(struct rte_pci_device *pci_dev)
{
+ struct rte_pci_driver *pci_drv = to_pci_driver(pci_dev->dev.driver);
uint16_t start, end;
int size;
FILE *fp;
@@ -1188,7 +1191,7 @@ static int virtio_resource_init_by_ioports(struct
rte_pci_device *pci_dev)
start, size);
/* can't support lsc interrupt without uio */
- pci_dev->driver->drv_flags &= ~RTE_PCI_DRV_INTR_LSC;
+ pci_drv->drv_flags &= ~RTE_PCI_DRV_INTR_LSC;
return 0;
}
@@ -1265,6 +1268,7 @@ eth_virtio_dev_init(struct rte_eth_dev *eth_dev)
struct virtio_net_config *config;
struct virtio_net_config local_config;
struct rte_pci_device *pci_dev;
+ struct rte_pci_driver *pci_drv;
RTE_BUILD_BUG_ON(RTE_PKTMBUF_HEADROOM < sizeof(struct virtio_net_hdr));
@@ -1286,6 +1290,7 @@ eth_virtio_dev_init(struct rte_eth_dev *eth_dev)
}
pci_dev = eth_dev->pci_dev;
+ pci_drv = to_pci_driver(pci_dev->dev.driver);
if (virtio_resource_init(pci_dev) < 0)
return -1;
@@ -1305,7 +1310,7 @@ eth_virtio_dev_init(struct rte_eth_dev *eth_dev)
/* If host does not support status then disable LSC */
if (!vtpci_with_feature(hw, VIRTIO_NET_F_STATUS))
- pci_dev->driver->drv_flags &= ~RTE_PCI_DRV_INTR_LSC;
+ pci_drv->drv_flags &= ~RTE_PCI_DRV_INTR_LSC;
rte_eth_copy_pci_info(eth_dev, pci_dev);
@@ -1388,7 +1393,7 @@ eth_virtio_dev_init(struct rte_eth_dev *eth_dev)
pci_dev->id.device_id);
/* Setup interrupt callback */
- if (pci_dev->driver->drv_flags & RTE_PCI_DRV_INTR_LSC)
+ if (pci_drv->drv_flags & RTE_PCI_DRV_INTR_LSC)
rte_intr_callback_register(&pci_dev->dev.intr_handle,
virtio_interrupt_handler, eth_dev);
@@ -1401,6 +1406,7 @@ static int
eth_virtio_dev_uninit(struct rte_eth_dev *eth_dev)
{
struct rte_pci_device *pci_dev;
+ struct rte_pci_driver *pci_drv;
struct virtio_hw *hw = eth_dev->data->dev_private;
PMD_INIT_FUNC_TRACE();
@@ -1413,6 +1419,7 @@ eth_virtio_dev_uninit(struct rte_eth_dev *eth_dev)
virtio_dev_close(eth_dev);
}
pci_dev = eth_dev->pci_dev;
+
[dpdk-dev] [RFC 0/3] Use common Linux tools to control DPDK ports
Ferruh Yigit writes: > This work is to make DPDK ports more visible and to enable using common > Linux tools to configure DPDK ports. This is a good goal. Only question - why use an additional kernel module to do this? Is it _JUST_ for ethtool support? I think the other stuff can be accomplished using netlink sockets + messages, no? The only trepidation I would have with something like this is the support from major vendors - out of tree modules are not generally supportable. Might be good to get some of the ethtool commands as netlink messages as well, then it is supportable with no 3rd party kernel modules. Especially since (continued below)... > Patch is based on KNI but contains only control functionality of it, > also this patch does not include any Linux kernel network driver as > part of it. > > Basically with the help of a kernel module (KCP), virtual Linux network > interfaces named as "dpdk$" are created per DPDK port, control messages > sent to these virtual interfaces are forwarded to DPDK, and response > sent back to Linux application. > > Virtual interfaces created when DPDK application started and destroyed > automatically when DPDK application terminated. > > Communication between kernel-space and DPDK done using netlink socket. ... you're already using a netlink socket here. > Currently implementation is not complete, sample support added for the > RFC, more functionality can be added based on community response. > > With this RFC Patch, supported: get/set mac address/mtu of DPDK devices, > getting stats from DPDK devices and some set of ethtool commands. I actually think there could be some additional features for debuggability with this approach, so in general I like goal - I just have implementation nit picks. -Aaron
[dpdk-dev] [PATCH 09/11] doc: refresh headers list
> -Original Message- > From: David Marchand [mailto:david.marchand at 6wind.com] > Sent: Saturday, January 16, 2016 3:11 PM > To: Mcnamara, John > Cc: dev at dpdk.org; Thomas Monjalon > Subject: Re: [dpdk-dev] [PATCH 09/11] doc: refresh headers list > > Hello John, > > On Tue, Jan 12, 2016 at 3:06 PM, Mcnamara, John > wrote: > >> -Original Message- > >> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of David Marchand > >> Sent: Sunday, January 10, 2016 12:51 PM > >> To: dev at dpdk.org > >> Cc: thomas.monjalon at dpdk.org > >> Subject: [dpdk-dev] [PATCH 09/11] doc: refresh headers list > >> > >> Since we are going to remove a header in next commit, let's first > >> refresh documentation. > > > > I don't like these parts of the docs that list files since they go out > > of date quite easily and, in general, the same information can be > > conveyed by just listing the directories. (That isn't future-proof > > either but it should be less subject to change.) > > Well, we could imagine something automatic (in the build process), but I > agree that the quickest solution is to get rid of it. > > > > > In this case you could just remove everything in the console section > > after the output from "ls x86_64-native-linuxapp-gcc" like this: > > > > > > Each build directory contains include files, libraries, and applications > like the following:: > > > > $ ls > > app tools > > configMAINTAINERS > > Makefile GNUmakefile > > drivers mk > > examples pkg > > doc README > > lib scripts > > LICENSE.GPL LICENSE.LGPL > > i686-native-linuxapp-gcc x86_64-native-linuxapp-gcc > > i686-native-linuxapp-icc x86_64-native-linuxapp-icc > > > > $ ls x86_64-native-linuxapp-gcc > > app build include kmod lib Makefile > > > > Well, from my pov, it is the same issue here. > How about just removing all those files listings ? > I am not sure they really help. Hi, I'm fine with that. I don't think the file listing adds much information to the previous paragraph. Or we could just add text that leaves out some of the information so that the reader doesn?t expect an exact representation and isn't confused when their file structure doesn't match. Something like: $ ls ... app config doc drivers examples lib ... i686-native-linuxapp-gcc i686-native-linuxapp-icc x86_64-native-linuxapp-gcc x86_64-native-linuxapp-icc ... John. --
[dpdk-dev] [PATCH v4 7/8] virtio: add 1.0 support
On 1/15/2016 12:34 PM, Yuanhan Liu wrote:
> Modern (v1.0) virtio pci device defines several pci capabilities.
> Each cap has a configure structure corresponding to it, and the
> cap.bar and cap.offset fields tell us where to find it.
>
[snip]
>
> +static void *
> +get_cfg_addr(struct rte_pci_device *dev, struct virtio_pci_cap *cap)
> +{
> + uint8_t bar= cap->bar;
> + uint32_t length = cap->length;
> + uint32_t offset = cap->offset;
> + uint8_t *base;
> +
> + if (bar > 5) {
> + PMD_INIT_LOG(ERR, "invalid bar: %u", bar);
> + return NULL;
> + }
> +
> + if (offset + length > dev->mem_resource[bar].len) {
offset + length could overflow 32bit limit
> + PMD_INIT_LOG(ERR,
> + "invalid cap: overflows bar space: %u > %"PRIu64,
> + offset + length, dev->mem_resource[bar].len);
> + return NULL;
> + }
> +
> +
[snip]
[dpdk-dev] [PATCH v4 7/8] virtio: add 1.0 support
On 1/15/2016 12:34 PM, Yuanhan Liu wrote:
> -static void
> +static int
> virtio_negotiate_features(struct virtio_hw *hw)
> {
> uint64_t host_features;
> @@ -949,6 +949,22 @@ virtio_negotiate_features(struct virtio_hw *hw)
> hw->guest_features = vtpci_negotiate_features(hw, host_features);
Here if we are not modern device, we should remove VIRTIO_F_VERSION_1 in
guest features.
> PMD_INIT_LOG(DEBUG, "features after negotiate = %"PRIx64,
> hw->guest_features);
> +
> + if (hw->modern) {
> + if (!vtpci_with_feature(hw, VIRTIO_F_VERSION_1)) {
> + PMD_INIT_LOG(ERR,
> + "VIRTIO_F_VERSION_1 features is not enabled.");
> + return -1;
> + }
> + vtpci_set_status(hw, VIRTIO_CONFIG_STATUS_FEATURES_OK);
> + if (!(vtpci_get_status(hw) & VIRTIO_CONFIG_STATUS_FEATURES_OK))
> {
> + PMD_INIT_LOG(ERR,
> + "failed to set FEATURES_OK status!");
> + return -1;
> + }
> + }
> +
> + return 0;
> }
[dpdk-dev] [PATCH v4 7/8] virtio: add 1.0 support
.On 1/15/2016 12:34 PM, Yuanhan Liu wrote:
> Modern (v1.0) virtio pci device defines several pci capabilities.
> Each cap has a configure structure corresponding to it, and the
> cap.bar and cap.offset fields tell us where to find it.
>
[snip]
> +
> +static inline void
> +io_write64_twopart(uint64_t val, uint32_t *lo, uint32_t *hi)
> +{
> + io_write32((uint32_t)val, lo);
> + io_write32(val >> 32, hi);
Firstly your second iowrite32 doesn't do the conversion. The conversion
is duplicated.
> +}
> +
> +static void
> +modern_read_dev_config(struct virtio_hw *hw, uint64_t offset,
here and there, size_t is more accurate for offset as we get it from
offsetof.
> +void *dst, int length)
> +{
> + int i;
> + uint8_t *p;
> + uint8_t old_gen, new_gen;
> +
> + do {
> + old_gen = io_read8(&hw->common_cfg->config_generation);
> +
> + p = dst;
> + for (i = 0; i < length; i++)
> + *p++ = io_read8((uint8_t *)hw->dev_cfg + offset + i);
> +
> + new_gen = io_read8(&hw->common_cfg->config_generation);
> + } while (old_gen != new_gen);
> +}
> +
> +static void
> +modern_write_dev_config(struct virtio_hw *hw, uint64_t offset,
> + const void *src, int length)
> +{
> + int i;
> + const uint8_t *p = src;
> +
> + for (i = 0; i < length; i++)
> + io_write8(*p++, (uint8_t *)hw->dev_cfg + offset + i);
> +}
> +
> +static uint64_t
> +modern_get_features(struct virtio_hw *hw)
> +{
> + uint32_t features_lo, features_hi;
> +
> + io_write32(0, &hw->common_cfg->device_feature_select);
> + features_lo = io_read32(&hw->common_cfg->device_feature);
> +
> + io_write32(1, &hw->common_cfg->device_feature_select);
> + features_hi = io_read32(&hw->common_cfg->device_feature);
> +
> + return ((uint64_t)(features_hi) << 32) | features_lo;
> +}
> +
> +static void
> +modern_set_features(struct virtio_hw *hw, uint64_t features)
> +{
> + io_write32(0, &hw->common_cfg->guest_feature_select);
> + io_write32(features & ((1ULL << 32) - 1),
again, duplicated conversion
> + &hw->common_cfg->guest_feature);
> +
> + io_write32(1, &hw->common_cfg->guest_feature_select);
[snip]
[dpdk-dev] [PATCH v4 2/8] virtio: introduce struct virtio_pci_ops
On 1/15/2016 12:34 PM, Yuanhan Liu wrote:
> +void
> +vtpci_write_dev_config(struct virtio_hw *hw, uint64_t offset,
> + void *src, int length)
> +{
> + hw->vtpci_ops->write_dev_cfg(hw, offset, src, length);
missed changing src to const.
> +}
[dpdk-dev] [RESEND PATCH] vhost_user: Make sure that memory map is set before attempting address translation
On 1/15/2016 4:10 PM, Pavel Fedin wrote: > Hello! > >> If this is the case, i am wondering whether we should include >> "malfunctioning clients" in commit message. It triggers me to think if >> there are existing buggy implementations. > Well... Can you suggest how to rephrase it? May be "if a client is > malfunctioning it can..."? I lack fantasy, really, and to tell > the truth i don't care that much about the exact phrasing, i'm OK with > everything. Thanks. Because there are not any existing malfunctioning clients which doesn't send SET_MEM_TABLE message and we think the check is OK anyway, personally I prefer simple phrases like: check memory table in SET_VRING_ADDR message. > >> Anyway, check is OK. > Kind regards, > Pavel Fedin > Senior Engineer > Samsung Electronics Research center Russia > > >
[dpdk-dev] [PATCH v2 0/5] Optimize memcpy for AVX512 platforms
On Sun, 17 Jan 2016 22:05:09 -0500 Zhihong Wang wrote: > This patch set optimizes DPDK memcpy for AVX512 platforms, to make full > utilization of hardware resources and deliver high performance. > > In current DPDK, memcpy holds a large proportion of execution time in > libs like Vhost, especially for large packets, and this patch can bring > considerable benefits. > > The implementation is based on the current DPDK memcpy framework, some > background introduction can be found in these threads: > http://dpdk.org/ml/archives/dev/2014-November/008158.html > http://dpdk.org/ml/archives/dev/2015-January/011800.html > > Code changes are: > > 1. Read CPUID to check if AVX512 is supported by CPU > > 2. Predefine AVX512 macro if AVX512 is enabled by compiler > > 3. Implement AVX512 memcpy and choose the right implementation based on > predefined macros > > 4. Decide alignment unit for memcpy perf test based on predefined macros Cool, I like it. How much impact does this have on VHOST?
[dpdk-dev] Proposal for a big eal / ethdev cleanup
Jan, I was waiting for some others feedbacks before going into the code. Glad to see you already tried this. On Mon, Jan 18, 2016 at 3:58 PM, Jan Viktorin wrote: > On Thu, 14 Jan 2016 11:38:16 +0100 > David Marchand wrote: >> - no need for a rte_pci_driver reference in rte_pci_device, since we >> have the rte_device driver > > This is an issue, see below. > >> >> - rte_pci_driver is modified to embed a rte_driver > > The rte_driver and rte_pci_driver are related in a much different way > at the moment. The meaning of rte_driver is more like an rte_module in > the current DPDK. > > In fact, we don't have any generic rte_driver suitable for this purpose. > Thus, the transition to this model needs to rename rte_driver to > rte_module and to introduce a new data structure named rte_driver. > > Quite confusing... but this is how I understand it. Hum, yes. Well, looking at current rte_driver, this code has been first thought as a way to load pmd through dso, so yes, this is more like module init. Then the hotplug has been hooked on this, adding to the confusion. > (What is the current relation between rte_pci_device and rte_pci_driver? > Is the rte_pci_driver a singleton? I doubt. Well, it cannot be, as it > is embedded in each eth_driver.) Not sure I understand the question. At the moment, a rte_pci_device references a rte_pci_driver. Associating those happens at pci "probe" time lib/librte_eal/common/eal_common_pci.c +202 I agree there is a pci_driver embedded in eth_driver, but that does not mean pci drivers must be eth drivers. > Another way, not that beautiful... Introduce rte_generic_driver and > rte_generic_device. (Or rte_gen_driver/rte_gen_device or > rte_bus_driver/rte_bus_device if you want). This enables to let the > rte_driver as it is and it avoids a lot of quite terrible transition > patches that can break everything. > >> - no more devinit and devuninit functions in rte_pci_driver, they can >> be moved as init / uninit functions in rte_driver > > The rte_driver has init/uninit already and its semantics seem to be > module_init and module_uninit. Ok, so what you propose is something like this ? - keep rte_driver as it is (init and uninit), I would say the name can be changed later. - add rte_bus_driver (idem, not sure it is a good name) in place of the rte_driver I mentioned in my initial mail. Rather than have init / uninit, how about attach / detach methods ? Regards, -- David Marchand
[dpdk-dev] [RFC 0/3] Use common Linux tools to control DPDK ports
On Fri, 15 Jan 2016 16:18:01 + Ferruh Yigit wrote: > This work is to make DPDK ports more visible and to enable using common > Linux tools to configure DPDK ports. > > Patch is based on KNI but contains only control functionality of it, > also this patch does not include any Linux kernel network driver as > part of it. I actually would like KNI to die and be replaced by something generic. Right now with KNI it is driver and hardware specific. It is almost as if there are three drivers for ixgbe, the Linux driver, the DPDK driver, and the KNI driver.
[dpdk-dev] [RFC 0/3] Use common Linux tools to control DPDK ports
On Mon, Jan 18, 2016 at 5:12 PM, Stephen Hemminger < stephen at networkplumber.org> wrote: > On Fri, 15 Jan 2016 16:18:01 + > Ferruh Yigit wrote: > > > This work is to make DPDK ports more visible and to enable using common > > Linux tools to configure DPDK ports. > > > > Patch is based on KNI but contains only control functionality of it, > > also this patch does not include any Linux kernel network driver as > > part of it. > > I actually would like KNI to die and be replaced by something generic. > Right now with KNI it is driver and hardware specific. It is almost as if > there > are three drivers for ixgbe, the Linux driver, the DPDK driver, and the > KNI driver. > Any ideas about what that would look like? Having the ability to send traffic to/from DPDK-owned ports from control plane applications that live outside of (and are ignorant of) DPDK is a platform requirement for our product. I'm assuming that isn't uncommon, but that could just be the nature of the types of products I've built over the years. That said, I'd love there to be something that performs better and plays nicer with the system than KNI. Jay
[dpdk-dev] [RFC 0/3] Use common Linux tools to control DPDK ports
On Mon, 18 Jan 2016 17:48:51 -0600 Jay Rolette wrote: > On Mon, Jan 18, 2016 at 5:12 PM, Stephen Hemminger < > stephen at networkplumber.org> wrote: > > > On Fri, 15 Jan 2016 16:18:01 + > > Ferruh Yigit wrote: > > > > > This work is to make DPDK ports more visible and to enable using common > > > Linux tools to configure DPDK ports. > > > > > > Patch is based on KNI but contains only control functionality of it, > > > also this patch does not include any Linux kernel network driver as > > > part of it. > > > > I actually would like KNI to die and be replaced by something generic. > > Right now with KNI it is driver and hardware specific. It is almost as if > > there > > are three drivers for ixgbe, the Linux driver, the DPDK driver, and the > > KNI driver. > > > > Any ideas about what that would look like? Having the ability to send > traffic to/from DPDK-owned ports from control plane applications that live > outside of (and are ignorant of) DPDK is a platform requirement for our > product. > > I'm assuming that isn't uncommon, but that could just be the nature of the > types of products I've built over the years. > > That said, I'd love there to be something that performs better and plays > nicer with the system than KNI. Maybe something using switchdev API in kernel? Or making the bifurcated driver model work? Or something more like netmap where actual driver code is in kernel for controlling hardware and only ring buffers need to be exposed. The existing DPDK although high performance suffers from lots of cases of DRY (https://en.wikipedia.org/wiki/Don%27t_repeat_yourself). For a recent example, we discovered that VLAN's don't work on I350 because the code to handle the workaround for byte swapping is not there in DPDK (it is in the Linux driver). Because DPDK causes there to be has two driver code bases, this kind of problem is bound to occur. I realize this is a very hard problem, and there is no quick solution. Any long term solution will require work in both spaces kernel and DPDK.
[dpdk-dev] [PATCH v2] cfgfile: support looking up sections by index
This is useful when sections have duplicate names.
Signed-off-by: Rich Lane
---
v1->v2:
- Added new symbol to version script.
lib/librte_cfgfile/rte_cfgfile.c | 16
lib/librte_cfgfile/rte_cfgfile.h | 23 +++
lib/librte_cfgfile/rte_cfgfile_version.map | 6 ++
3 files changed, 45 insertions(+)
diff --git a/lib/librte_cfgfile/rte_cfgfile.c b/lib/librte_cfgfile/rte_cfgfile.c
index a677dad..0bb40a4 100644
--- a/lib/librte_cfgfile/rte_cfgfile.c
+++ b/lib/librte_cfgfile/rte_cfgfile.c
@@ -333,6 +333,22 @@ rte_cfgfile_section_entries(struct rte_cfgfile *cfg, const
char *sectionname,
return i;
}
+int
+rte_cfgfile_section_entries_by_index(struct rte_cfgfile *cfg, int index,
+ struct rte_cfgfile_entry *entries, int max_entries)
+{
+ int i;
+ const struct rte_cfgfile_section *sect;
+
+ if (index >= cfg->num_sections)
+ return -1;
+
+ sect = cfg->sections[index];
+ for (i = 0; i < max_entries && i < sect->num_entries; i++)
+ entries[i] = *sect->entries[i];
+ return i;
+}
+
const char *
rte_cfgfile_get_entry(struct rte_cfgfile *cfg, const char *sectionname,
const char *entryname)
diff --git a/lib/librte_cfgfile/rte_cfgfile.h b/lib/librte_cfgfile/rte_cfgfile.h
index d443782..8e69971 100644
--- a/lib/librte_cfgfile/rte_cfgfile.h
+++ b/lib/librte_cfgfile/rte_cfgfile.h
@@ -155,6 +155,29 @@ int rte_cfgfile_section_entries(struct rte_cfgfile *cfg,
struct rte_cfgfile_entry *entries,
int max_entries);
+/** Get section entries as key-value pairs
+*
+* The index of a section is the same as the index of its name in the
+* result of rte_cfgfile_sections. This API can be used when there are
+* multiple sections with the same name.
+*
+* @param cfg
+* Config file
+* @param index
+* Section index
+* @param entries
+* Pre-allocated array of at least max_entries entries where the section
+* entries are stored as key-value pair after successful invocation
+* @param max_entries
+* Maximum number of section entries to be stored in entries array
+* @return
+* Number of entries populated on success, negative error code otherwise
+*/
+int rte_cfgfile_section_entries_by_index(struct rte_cfgfile *cfg,
+ int index,
+ struct rte_cfgfile_entry *entries,
+ int max_entries);
+
/** Get value of the named entry in named config file section
*
* @param cfg
diff --git a/lib/librte_cfgfile/rte_cfgfile_version.map
b/lib/librte_cfgfile/rte_cfgfile_version.map
index bf6c6fd..f6a27a9 100644
--- a/lib/librte_cfgfile/rte_cfgfile_version.map
+++ b/lib/librte_cfgfile/rte_cfgfile_version.map
@@ -13,3 +13,9 @@ DPDK_2.0 {
local: *;
};
+
+DPDK_2.3 {
+ global:
+
+ rte_cfgfile_section_entries_by_index;
+} DPDK_2.0;
--
1.9.1
[dpdk-dev] [PATCH] i40e: fix vlan filtering
VLAN filtering was always performed, even if hw_vlan_filter was
disabled. During device initialization, default filter
RTE_MACVLAN_PERFECT_MATCH was applied. In this situation, all incoming
VLAN frames were dropped by the card (increase of the register RUPP - Rx
Unsupported Protocol).
In order to restore default behavior, if HW VLAN filtering is activated,
set a filter to match MAC and VLAN. If not, set a filter to only match
MAC.
Signed-off-by: Julien Meunier
Signed-off-by: David Marchand
---
drivers/net/i40e/i40e_ethdev.c | 39 ++-
drivers/net/i40e/i40e_ethdev.h | 1 +
2 files changed, 39 insertions(+), 1 deletion(-)
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index bf6220d..ef9d578 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -2332,6 +2332,13 @@ i40e_vlan_offload_set(struct rte_eth_dev *dev, int mask)
struct i40e_pf *pf = I40E_DEV_PRIVATE_TO_PF(dev->data->dev_private);
struct i40e_vsi *vsi = pf->main_vsi;
+ if (mask & ETH_VLAN_FILTER_MASK) {
+ if (dev->data->dev_conf.rxmode.hw_vlan_filter)
+ i40e_vsi_config_vlan_filter(vsi, TRUE);
+ else
+ i40e_vsi_config_vlan_filter(vsi, FALSE);
+ }
+
if (mask & ETH_VLAN_STRIP_MASK) {
/* Enable or disable VLAN stripping */
if (dev->data->dev_conf.rxmode.hw_vlan_strip)
@@ -4156,6 +4163,34 @@ fail_mem:
return NULL;
}
+/* Configure vlan filter on or off */
+int
+i40e_vsi_config_vlan_filter(struct i40e_vsi *vsi, bool on)
+{
+ struct i40e_hw *hw = I40E_VSI_TO_HW(vsi);
+ struct i40e_mac_filter_info filter;
+ int ret;
+
+ rte_memcpy(&filter.mac_addr,
+ (struct ether_addr *)(hw->mac.perm_addr), ETH_ADDR_LEN);
+ ret = i40e_vsi_delete_mac(vsi, &filter.mac_addr);
+
+ if (on) {
+ /* Filter to match MAC and VLAN */
+ filter.filter_type = RTE_MACVLAN_PERFECT_MATCH;
+ } else {
+ /* Filter to match only MAC */
+ filter.filter_type = RTE_MAC_PERFECT_MATCH;
+ }
+
+ ret |= i40e_vsi_add_mac(vsi, &filter);
+
+ if (ret)
+ PMD_DRV_LOG(INFO, "Update VSI failed to %s vlan filter",
+ on ? "enable" : "disable");
+ return ret;
+}
+
/* Configure vlan stripping on or off */
int
i40e_vsi_config_vlan_stripping(struct i40e_vsi *vsi, bool on)
@@ -4203,9 +4238,11 @@ i40e_dev_init_vlan(struct rte_eth_dev *dev)
{
struct rte_eth_dev_data *data = dev->data;
int ret;
+ int mask = 0;
/* Apply vlan offload setting */
- i40e_vlan_offload_set(dev, ETH_VLAN_STRIP_MASK);
+ mask = ETH_VLAN_STRIP_MASK | ETH_VLAN_FILTER_MASK;
+ i40e_vlan_offload_set(dev, mask);
/* Apply double-vlan setting, not implemented yet */
diff --git a/drivers/net/i40e/i40e_ethdev.h b/drivers/net/i40e/i40e_ethdev.h
index 1f9792b..5505d72 100644
--- a/drivers/net/i40e/i40e_ethdev.h
+++ b/drivers/net/i40e/i40e_ethdev.h
@@ -551,6 +551,7 @@ void i40e_vsi_queues_unbind_intr(struct i40e_vsi *vsi);
int i40e_vsi_vlan_pvid_set(struct i40e_vsi *vsi,
struct i40e_vsi_vlan_pvid_info *info);
int i40e_vsi_config_vlan_stripping(struct i40e_vsi *vsi, bool on);
+int i40e_vsi_config_vlan_filter(struct i40e_vsi *vsi, bool on);
uint64_t i40e_config_hena(uint64_t flags);
uint64_t i40e_parse_hena(uint64_t flags);
enum i40e_status_code i40e_fdir_setup_tx_resources(struct i40e_pf *pf);
--
2.1.4
