Re: [dpdk-dev] [PATCH v4 1/6] eventdev: introduce event driven programming model
On Wed, Jan 25, 2017 at 10:36:21PM +, Eads, Gage wrote:
> > > > > Subject: [dpdk-dev] [PATCH v4
> > > 1/6] eventdev: introduce event driven > > programming model > >
> > > > > +/** > > + * Enqueue a burst
> > > of events objects or an event object supplied > > in > >
> > > *rte_event* > > + * structure on an event device designated by its
> > > *dev_id* > > through the event + * port specified by *port_id*. Each
> > > event > > object specifies the event queue on + * which it will be
> > > enqueued.
> > > > > + *
> > > > > + * The *nb_events* parameter is the number of event objects to
> > > > > enqueue which are + * supplied in the *ev* array of *rte_event*
> > > > > structure.
> > > > > + *
> > > > > + * The rte_event_enqueue_burst() function returns the number of
> > > + > > * events objects it actually enqueued. A return value equal to
> > > > > *nb_events* + * means that all event objects have been enqueued.
> > > > > + *
> > > > > + * @param dev_id
> > > > > + * The identifier of the device.
> > > > > + * @param port_id
> > > > > + * The identifier of the event port.
> > > > > + * @param ev
> > > > > + * Points to an array of *nb_events* objects of type *rte_event*
> > > > structure
> > > > > + * which contain the event object enqueue operations to be
> > > > processed.
> > > > > + * @param nb_events
> > > > > + * The number of event objects to enqueue, typically number of
> > > > > + * rte_event_port_enqueue_depth() available for this port.
> > > > > + *
> > > > > + * @return
> > > > > + * The number of event objects actually enqueued on the event
> > > > device. The
> > > > > + * return value can be less than the value of the *nb_events*
> > > > parameter
> > > > > when
> > > > > + * the event devices queue is full or if invalid parameters are
> > > > specified in a
> > > > > + * *rte_event*. If return value is less than *nb_events*, the
> > > > remaining events
> > > > > + * at the end of ev[] are not consumed,and the caller has to
> > take
> > > > care of
> > > > > them
> > > > > + *
> > > > > + * @see rte_event_port_enqueue_depth() + */ +uint16_t > >
> > > +rte_event_enqueue_burst(uint8_t dev_id, uint8_t port_id,
> > > > > + const struct rte_event ev[], uint16_t
> > nb_events);
> > > >
> > > > There are a number of reasons this operation could fail to enqueue
> > > all > the events, including:
> > > > - Backpressure
> > > > - Invalid port ID
> > > > - Invalid queue ID
> > > > - Invalid sched type when a queue is configured for ATOMIC_ONLY, >
> > > ORDERED_ONLY, or PARALLEL_ONLY > - ...
> > > >
> > > > The current API doesn't provide a straightforward way to determine
> > > the > cause of a failure. This is a particular issue on event PMDs
> > > that can > backpressure, where the app may want to treat that case
> > > differently > than the other failure cases.
> > > >
> > > > Could we change the return type to int16_t, and define a set of
> > > error > cases (e.g. -ENOSPC for backpressure, -EINVAL for an invalid
> > argument)?
> > > > (With corresponding changes needed in the PMD API) Similarly we
> > > could > change rte_event_dequeue_burst() to return an int16_t, with
> > > -EINVAL as > a possible error case.
> > >
> > > Use rte_errno instead, I suggest. That's what it's there for.
> > >
> > > /Bruce
> >
> > That makes sense. In that case, the API comment could be tweaked like so:
> >
> >* If the return value is less than *nb_events*, the remaining events at
> > the
> >* end of ev[] are not consumed and the caller has to take care of them,
> > and
> >* rte_errno is set accordingly. Possible errno values include:
> >* - EINVAL - The port ID is invalid, an event's queue ID is invalid, or
> > an
> >*event's sched type doesn't match the capabilities of the
> >*destination queue.
> >* - ENOSPC - The event port was backpressured and unable to enqueue one
> > or
> >*more events.
>
> However it seems better to use a signed integer for the dequeue burst return
> value, if it is to use rte_errno. Application code could be simplified:
>
> (signed return value)
> ret = rte_event_dequeue_burst(...);
> if (ret < 0)
> rte_panic("Dequeued returned errno %d\n", rte_errno);
>
> vs.
>
> (unsigned return value)
> ret = rte_event_dequeue_burst(...);
> if (ret == 0 && rte_errno != 0)
> rte_panic("Dequeued returned errno %d\n", rte_errno);
>
> And with an unsigned return value, all dequeue implementations would have to
> clear rte_errno when no events are dequeued.
Gage,
Just to understand, what is the expected application behavior if the
implementation returns -ENOSPC
Apart for the above SW driver behavior, I think, HW implementation has two more
different behavior
a) Implementation make sure that it n
Re: [dpdk-dev] [PATCH v4 0/4] Introduce new performance test application
> -Original Message- > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of De Lara Guarch, > Pablo > Sent: Wednesday, January 25, 2017 3:59 PM > To: Mrozowicz, SlawomirX; dev@dpdk.org > Cc: Mrozowicz, SlawomirX > Subject: Re: [dpdk-dev] [PATCH v4 0/4] Introduce new performance test > application > > > > > -Original Message- > > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Slawomir > > Mrozowicz > > Sent: Wednesday, January 25, 2017 4:28 PM > > To: dev@dpdk.org > > Cc: Mrozowicz, SlawomirX > > Subject: [dpdk-dev] [PATCH v4 0/4] Introduce new performance test > > application > > > ... > > > > Declan Doherty (2) > > cryptodev: add functions to retrieve device info > > app/crypto-perf: introduce new performance test application > > > > Slawomir Mrozowicz (3): > > cryptodev: add functions to retrieve device info > > app/crypto-perf: introduce new performance test application > > doc: describe new performance test application > > > > Marcin Kerlin (3) > > cryptodev: add functions to retrieve device info > > app/crypto-perf: introduce new performance test application > > app/crypto-perf: add test vectors files > > > > Piotr Azarewicz (2) > > app/crypto-perf: introduce new performance test application > > doc: describe new performance test application > > > > Michal Kobylinski (1) > > app/crypto-perf: introduce new performance test application > > Series-acked-by: Pablo de Lara Applied to dpdk-next-crypto. Thanks, Pablo
Re: [dpdk-dev] [PATCH 2/3] net/cxgbe: remove unused variable usage
On 1/26/2017 4:41 AM, Rahul Lakkireddy wrote:
> On Wednesday, January 01/25/17, 2017 at 17:43:57 +0530, Ferruh Yigit wrote:
>> On 1/24/2017 8:48 PM, Emmanuel Roullit wrote:
>>> Found with clang static analysis:
>>> drivers/net/cxgbe/sge.c:900:3: warning:
>>> Value stored to 'in_use' is never read
>>> in_use += q->size;
>>> ^ ~~~
>>>
>>> Fixes: c167acb61278 ("net/cxgbe: use I/O device memory read/write API")
>
> This fixes line seems to be wrong. Should be:
>
>
>>>
>>> Signed-off-by: Emmanuel Roullit
> Fixes: 4a01078b4fd1 ("cxgbe: add Tx support")
Cc: sta...@dpdk.org
Acked-by: Rahul Lakkireddy
Applied to dpdk-next-net/master, thanks.
(patch 2/3 and 3/3 merged)
Re: [dpdk-dev] [PATCH 1/3] net/cxgbe: init data value before reading seeprom
On 1/25/2017 12:12 PM, Ferruh Yigit wrote:
> On 1/24/2017 8:48 PM, Emmanuel Roullit wrote:
>> data value could have been garbage if VPD access timed out for VPD read
>> request could not been issued.
>>
>> Found with clang static analysis:
>> drivers/net/cxgbe/base/t4_hw.c:1577:22:
>> warning: The left operand of '&' is a garbage value
>> } while ((stats_reg & 0x1) && --max_poll);
>> ~ ^
>>
>> Fixes: 17ba077c5c54 ("net/cxgbe: support register dump")
>>
>> Signed-off-by: Emmanuel Roullit
>
> Applied to dpdk-next-net/master, thanks.
>
Fixes: fe0bd9ee5da3 ("net/cxgbe: support EEPROM access")
Cc: sta...@dpdk.org
Re: [dpdk-dev] [PATCH] net/bonding: remove useless assignment
On 1/25/2017 12:11 PM, Ferruh Yigit wrote:
> On 1/24/2017 9:15 PM, Emmanuel Roullit wrote:
>> Found with clang static analysis:
>> drivers/net/bonding/rte_eth_bond_pmd.c:903:3:
>> warning: Value stored to 'num_not_send' is never read
>> num_not_send += slave_bufs_pkts[RTE_MAX_ETHPORTS] - num_send;
>> ^
>>
>> Fixes: 73db5badb042 ("net: align ethdev and eal driver names")
>>
>> Signed-off-by: Emmanuel Roullit
>
> Applied to dpdk-next-net/master, thanks.
Fixes: 06fe78b98ccd ("bond: add mode 6")
Cc: sta...@dpdk.org
Re: [dpdk-dev] [PATCHv6 00/33] NXP DPAA2 PMD
On 1/23/2017 5:56 PM, Ferruh Yigit wrote: > On 1/23/2017 11:59 AM, Hemant Agrawal wrote: > <...> > >> >> Hemant Agrawal (33): >> mk/dpaa2: add the crc support to the machine type >> drivers/common/dpaa2: adding qbman driver >> bus/fslmc: introducing fsl-mc bus driver >> bus/fslmc: introduce mc object functions >> bus/fslmc: add mc dpni object support >> bus/fslmc: add mc dpio object support >> bus/fslmc: add mc dpbp object support >> bus/fslmc: add mc dpseci object support >> eal/vfio: adding vfio utility functions in map file >> bus/fslmc: add vfio support >> bus/fslmc: scan for net and sec devices >> net/dpaa2: introducing NXP dpaa2 pmd driver >> doc: add dpaa2 nic details >> bus/fslmc: add debug log message support >> drivers/common/dpaa2: dpio portal driver >> drivers/pool/dpaa2: adding hw offloaded mempool >> drivers/common/dpaa2: dpio routine to affine to crypto threads >> net/dpaa2: adding eth ops to dpaa2 >> net/dpaa2: add rss flow distribution >> net/dpaa2: configure mac address at init >> net/dpaa2: attach the buffer pool to dpni >> net/dpaa2: add support for l3 and l4 checksum offload >> net/dpaa2: add support for promiscuous mode >> net/dpaa2: add mtu config support >> net/dpaa2: add packet rx and tx support >> net/dpaa2: rx packet parsing and packet type support >> net/dpaa2: link status update >> net/dpaa2: basic stats support >> net/dpaa2: enable stashing for LS2088A devices >> net/dpaa2: add support for non hw buffer pool packet transmit >> net/dpaa2: enabling the use of physical addresses >> bus/fslmc: add support for dmamap to ARM SMMU >> drivers/common/dpaa2: frame queue based dq storage alloc >> > <...> >> 66 files changed, 15984 insertions(+), 5 deletions(-) > > I have some concerns about this PMD, > > - This is a big one, as seen above, and it is hard to review it all, I > don't feel confident about the amount of review done, more reviewers are > welcome. And we are already post RC1. > > - Although this driver introduces a new bus type, in some parts, driver > still has virtual devices like usage, perhaps this is not because of > this PMD but mostly because of overall dpdk bus structure. Still I have > concerns about getting driver like this, and would like to hear more > comments. As a result of above concerns, I propose postponing this PMD to 17.05 release. The dependent rte_bus just get into main repo less than two weeks ago, also this driver comes with a few new things first of its kind, and it matters to make first samples correct. I believe it is good to let the PMD be around a little more to give chance to both PMD and rte_bus to become more mature. Thanks, ferruh
Re: [dpdk-dev] [PATCHv6 16/33] drivers/pool/dpaa2: adding hw offloaded mempool
Hello Neil,
> -Original Message-
> From: Neil Horman [mailto:nhor...@tuxdriver.com]
> Sent: Wednesday, January 25, 2017 8:37 PM
> To: Shreyansh Jain
> Cc: Thomas Monjalon ; Hemant Agrawal
> ; Ferruh Yigit ;
> dev@dpdk.org; bruce.richard...@intel.com; john.mcnam...@intel.com;
> jerin.ja...@caviumnetworks.com
> Subject: Re: [dpdk-dev] [PATCHv6 16/33] drivers/pool/dpaa2: adding hw
> offloaded mempool
>
> On Wed, Jan 25, 2017 at 01:34:47PM +, Shreyansh Jain wrote:
> >
> >
> > > -Original Message-
> > > From: Neil Horman [mailto:nhor...@tuxdriver.com]
> > > Sent: Wednesday, January 25, 2017 5:53 PM
> > > To: Thomas Monjalon
> > > Cc: Hemant Agrawal ; Ferruh Yigit
> > > ; Shreyansh Jain ;
> > > dev@dpdk.org; bruce.richard...@intel.com; john.mcnam...@intel.com;
> > > jerin.ja...@caviumnetworks.com
> > > Subject: Re: [dpdk-dev] [PATCHv6 16/33] drivers/pool/dpaa2: adding hw
> > > offloaded mempool
> > >
> > > On Tue, Jan 24, 2017 at 06:28:59PM +0100, Thomas Monjalon wrote:
> > > > 2017-01-24 20:07, Hemant Agrawal:
> > > > > On 1/24/2017 4:19 PM, Ferruh Yigit wrote:
> > > > > > On 1/24/2017 9:12 AM, Shreyansh Jain wrote:
> > > > > >> On Monday 23 January 2017 11:04 PM, Ferruh Yigit wrote:
> > > > > >>> On 1/23/2017 11:59 AM, Hemant Agrawal wrote:
> > > > > +# library dependencies
> > > > > +DEPDIRS-$(CONFIG_RTE_LIBRTE_DPAA2_POOL) += lib/librte_eal
> > > > > +DEPDIRS-$(CONFIG_RTE_LIBRTE_DPAA2_POOL) += lib/librte_mempool
> > > > > +DEPDIRS-$(CONFIG_RTE_LIBRTE_DPAA2_POOL) +=
> > > lib/librte_common_dpaa2_qbman
> > > > > >>>
> > > > > >>> This dependeny doesn not looks correct, there is no folder like
> that.
> > > > > >>
> > > > > >> This is something even I need to understand. From the DEPDIRS what
> I
> > > > > >> understood was that though it refers to a directory, it
> essentially
> > > > > >> links libraries in build/lib/*.
> > > > > >>
> > > > > >> Further, somehow the development is deploying drivers/bus,
> > > > > >> drivers/common and drivers/pool in lib/* under the name specified
> as
> > > > > >> LIB in Makefile. My understanding was that it is expected behavior
> and
> > > > > >> not special because of drivers folder.
> > > > > >>
> > > > > >> Thus, above line only links lib/librte_common_dpaa2_qbman
> generated by
> > > > > >> drivers/common/dpaa2/qbman code.
> > > > > >>
> > > > > >> In fact, I think, this might also one of the issues why a parallel
> > > > > >> shared build fails for DPAA2 PMD (added in Cover letter).
> > > > > >> The dependency graph cannot create a graph for drivers/common
> > > > > >> as dependency for drivers/net or drivers/bus and hence parallel
> build
> > > > > >> fails because of missing libraries which are being parallely
> compiled.
> > > > > >
> > > > > > DEPDIRS-y is mainly to resolve dependencies for compilation order,
> and
> > > > > > should point to the folder,
> > > > > >
> > > > > > Following line will cause "librte_eal" to be compiled before
> driver:
> > > > > > DEPDIRS-$(CONFIG_RTE_LIBRTE_DPAA2_POOL) += lib/librte_eal
> > > > > >
> > > > > > So "lib/librte_common_dpaa2_qbman" does not makes more sense, since
> > > > > > there is no folder like that.
> > > > > >
> > > > > >
> > > > > > Somewhere in the history, with following commit, DEPDIRS-y gained a
> > > side
> > > > > > effect, it has been used to set dynamic linking dependencies, to
> fix
> > > > > > underlinking issue:
> > > > > > bf5a46fa5972 ("mk: generate internal library dependencies")
> > > > > >
> > > > > > I guess you are having that line to benefit from this side effect,
> but
> > > > > > this can be done with following more properly:
> > > > > > LDLIBS += lib/librte_common_dpaa2_qbman
> > > > > >
> > > > > >
> > > > > > To resolve the drivers/net to drivers/common dependency, following
> line
> > > > > > in this Makefile should work:
> > > > > > DEPDIRS-$(CONFIG_RTE_LIBRTE_DPAA2_PMD) += drivers/common/dpaa2
> > > > > >
> > > > > > This adds following, which will cause "drivers/common" compiled
> before
> > > > > > any "drivers/net":
> > > > > > LOCAL_DEPDIRS-drivers/net += drivers/common
> > > > >
> > > > > Thanks for your suggestion. This is one thing, I am not yet able to
> fix.
> > > > >
> > > > > Based on your suggestions:
> > > > > e.g.
> > > > > LDLIBS += -lrte_common_dpaa2_qbman
> > > > > DEPDIRS-$(CONFIG_RTE_LIBRTE_FSLMC_BUS) += drivers/common/dpaa2
> > > > >
> > > > > It does add entry in the ".depdirs"
> > > > > ./arm64-dpaa2-linuxapp-gcc/.depdirs:168:LOCAL_DEPDIRS-drivers/bus +=
> > > > > drivers/common
> > > > > ./arm64-dpaa2-linuxapp-gcc/.depdirs:170:LOCAL_DEPDIRS-drivers += lib
> > > > > ./arm64-dpaa2-linuxapp-gcc/.depdirs:172:LOCAL_DEPDIRS-drivers += lib
> > > > > ./arm64-dpaa2-linuxapp-gcc/.depdirs:174:LOCAL_DEPDIRS-drivers/pool +=
> > > > > drivers/common
> > > > >
> > > > > However, we keep on getting:
> > > > > LD librte_bus_fslmc.so.1.1
> > > > > aarch64-linux-gnu-gcc: error: drivers/common/dpaa2: No such file or
> > > > > directory
> >
Re: [dpdk-dev] [PATCHv6 00/33] NXP DPAA2 PMD
On 1/26/2017 5:25 PM, Ferruh Yigit wrote: On 1/23/2017 5:56 PM, Ferruh Yigit wrote: On 1/23/2017 11:59 AM, Hemant Agrawal wrote: <...> Hemant Agrawal (33): mk/dpaa2: add the crc support to the machine type drivers/common/dpaa2: adding qbman driver bus/fslmc: introducing fsl-mc bus driver bus/fslmc: introduce mc object functions bus/fslmc: add mc dpni object support bus/fslmc: add mc dpio object support bus/fslmc: add mc dpbp object support bus/fslmc: add mc dpseci object support eal/vfio: adding vfio utility functions in map file bus/fslmc: add vfio support bus/fslmc: scan for net and sec devices net/dpaa2: introducing NXP dpaa2 pmd driver doc: add dpaa2 nic details bus/fslmc: add debug log message support drivers/common/dpaa2: dpio portal driver drivers/pool/dpaa2: adding hw offloaded mempool drivers/common/dpaa2: dpio routine to affine to crypto threads net/dpaa2: adding eth ops to dpaa2 net/dpaa2: add rss flow distribution net/dpaa2: configure mac address at init net/dpaa2: attach the buffer pool to dpni net/dpaa2: add support for l3 and l4 checksum offload net/dpaa2: add support for promiscuous mode net/dpaa2: add mtu config support net/dpaa2: add packet rx and tx support net/dpaa2: rx packet parsing and packet type support net/dpaa2: link status update net/dpaa2: basic stats support net/dpaa2: enable stashing for LS2088A devices net/dpaa2: add support for non hw buffer pool packet transmit net/dpaa2: enabling the use of physical addresses bus/fslmc: add support for dmamap to ARM SMMU drivers/common/dpaa2: frame queue based dq storage alloc <...> 66 files changed, 15984 insertions(+), 5 deletions(-) I have some concerns about this PMD, - This is a big one, as seen above, and it is hard to review it all, I don't feel confident about the amount of review done, more reviewers are welcome. And we are already post RC1. - Although this driver introduces a new bus type, in some parts, driver still has virtual devices like usage, perhaps this is not because of this PMD but mostly because of overall dpdk bus structure. Still I have concerns about getting driver like this, and would like to hear more comments. As a result of above concerns, I propose postponing this PMD to 17.05 release. The dependent rte_bus just get into main repo less than two weeks ago, also this driver comes with a few new things first of its kind, and it matters to make first samples correct. I believe it is good to let the PMD be around a little more to give chance to both PMD and rte_bus to become more mature. I agree that this driver is coming with few new thing and it is taking time to come up with agreeable and good solution for some of this new stuff. Finalizing the right framework for adding SoC based drivers took a little longer than expected. But thanks to Thomas help in the last that we got the basic bus framework integrated. Thomos- is it possible to integrate it early in 17.05 cycle, rather than waiting till end? Thanks, ferruh
[dpdk-dev] [PATCH] devtools: update headline prefix for drivers
For the patches that touch multiple drivers in same driver group, script forces headline prefix start with drv group. Like for net/a net/b net/c, patch title should be "net: x y z" Update rule to let "driver" prefix in headline, for above sample patch title becomes: "drivers/net: x y z" This prevents patch confused with library with same name. Signed-off-by: Ferruh Yigit --- devtools/check-git-log.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/devtools/check-git-log.sh b/devtools/check-git-log.sh index 62b5f43..9ccef66 100755 --- a/devtools/check-git-log.sh +++ b/devtools/check-git-log.sh @@ -87,7 +87,7 @@ bad=$(for commit in $commits ; do if [ $(echo "$drvgrp" | wc -l) -gt 1 ] ; then echo "$headline" | grep -v '^drivers:' elif [ $(echo "$drv" | wc -l) -gt 1 ] ; then - echo "$headline" | grep -v "^$drvgrp" + echo "$headline" | grep -v "^drivers/$drvgrp" else echo "$headline" | grep -v "^$drv" fi -- 2.9.3
[dpdk-dev] [PATCH] drivers/net: make PCI device id struct const
Signed-off-by: Ferruh Yigit
---
drivers/net/bnx2x/bnx2x_ethdev.c | 4 ++--
drivers/net/bnxt/bnxt_ethdev.c | 2 +-
drivers/net/cxgbe/cxgbe_ethdev.c | 2 +-
drivers/net/ena/ena_ethdev.c | 2 +-
drivers/net/nfp/nfp_net.c| 2 +-
drivers/net/qede/qede_ethdev.c | 4 ++--
6 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/net/bnx2x/bnx2x_ethdev.c b/drivers/net/bnx2x/bnx2x_ethdev.c
index d149468..a0b0dfa 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 BROADCOM_PCI_VENDOR_ID 0x14E4
-static struct rte_pci_id pci_id_bnx2x_map[] = {
+static const struct rte_pci_id pci_id_bnx2x_map[] = {
{ RTE_PCI_DEVICE(BROADCOM_PCI_VENDOR_ID, CHIP_NUM_57800) },
{ RTE_PCI_DEVICE(BROADCOM_PCI_VENDOR_ID, CHIP_NUM_57711) },
{ RTE_PCI_DEVICE(BROADCOM_PCI_VENDOR_ID, CHIP_NUM_57810) },
@@ -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 const struct rte_pci_id pci_id_bnx2xvf_map[] = {
{ RTE_PCI_DEVICE(BROADCOM_PCI_VENDOR_ID, CHIP_NUM_57800_VF) },
{ RTE_PCI_DEVICE(BROADCOM_PCI_VENDOR_ID, CHIP_NUM_57810_VF) },
{ RTE_PCI_DEVICE(BROADCOM_PCI_VENDOR_ID, CHIP_NUM_57811_VF) },
diff --git a/drivers/net/bnxt/bnxt_ethdev.c b/drivers/net/bnxt/bnxt_ethdev.c
index 501c97d..d1b2518 100644
--- a/drivers/net/bnxt/bnxt_ethdev.c
+++ b/drivers/net/bnxt/bnxt_ethdev.c
@@ -92,7 +92,7 @@ static const char bnxt_version[] =
#define BROADCOM_DEV_ID_57414_MF 0x16ec
#define BROADCOM_DEV_ID_57416_MF 0x16ee
-static struct rte_pci_id bnxt_pci_id_map[] = {
+static const struct rte_pci_id bnxt_pci_id_map[] = {
{ RTE_PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, BROADCOM_DEV_ID_57301) },
{ RTE_PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, BROADCOM_DEV_ID_57302) },
{ RTE_PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, BROADCOM_DEV_ID_57304_PF) },
diff --git a/drivers/net/cxgbe/cxgbe_ethdev.c b/drivers/net/cxgbe/cxgbe_ethdev.c
index 64345e3..4d543a7 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 const struct rte_pci_id cxgb4_pci_tbl[] = {
#define CH_PCI_DEVICE_ID_FUNCTION 0x4
#define PCI_VENDOR_ID_CHELSIO 0x1425
diff --git a/drivers/net/ena/ena_ethdev.c b/drivers/net/ena/ena_ethdev.c
index 88a4977..a580345 100644
--- a/drivers/net/ena/ena_ethdev.c
+++ b/drivers/net/ena/ena_ethdev.c
@@ -177,7 +177,7 @@ static const struct ena_stats ena_stats_ena_com_strings[] =
{
#defineENA_TX_OFFLOAD_NOTSUP_MASK \
(PKT_TX_OFFLOAD_MASK ^ ENA_TX_OFFLOAD_MASK)
-static struct rte_pci_id pci_id_ena_map[] = {
+static const struct rte_pci_id pci_id_ena_map[] = {
{ RTE_PCI_DEVICE(PCI_VENDOR_ID_AMAZON, PCI_DEVICE_ID_ENA_VF) },
{ RTE_PCI_DEVICE(PCI_VENDOR_ID_AMAZON, PCI_DEVICE_ID_ENA_LLQ_VF) },
{ .device_id = 0 },
diff --git a/drivers/net/nfp/nfp_net.c b/drivers/net/nfp/nfp_net.c
index ab2d331..1020d9e 100644
--- a/drivers/net/nfp/nfp_net.c
+++ b/drivers/net/nfp/nfp_net.c
@@ -2583,7 +2583,7 @@ nfp_net_init(struct rte_eth_dev *eth_dev)
return 0;
}
-static struct rte_pci_id pci_id_nfp_net_map[] = {
+static const struct rte_pci_id pci_id_nfp_net_map[] = {
{
RTE_PCI_DEVICE(PCI_VENDOR_ID_NETRONOME,
PCI_DEVICE_ID_NFP6000_PF_NIC)
diff --git a/drivers/net/qede/qede_ethdev.c b/drivers/net/qede/qede_ethdev.c
index 5e8e97e..0494dbd 100644
--- a/drivers/net/qede/qede_ethdev.c
+++ b/drivers/net/qede/qede_ethdev.c
@@ -2288,7 +2288,7 @@ static int qedevf_eth_dev_uninit(struct rte_eth_dev
*eth_dev)
return qede_dev_common_uninit(eth_dev);
}
-static struct rte_pci_id pci_id_qedevf_map[] = {
+static const struct rte_pci_id pci_id_qedevf_map[] = {
#define QEDEVF_RTE_PCI_DEVICE(dev) RTE_PCI_DEVICE(PCI_VENDOR_ID_QLOGIC, dev)
{
QEDEVF_RTE_PCI_DEVICE(PCI_DEVICE_ID_QLOGIC_NX2_VF)
@@ -2302,7 +2302,7 @@ static struct rte_pci_id pci_id_qedevf_map[] = {
{.vendor_id = 0,}
};
-static struct rte_pci_id pci_id_qede_map[] = {
+static const struct rte_pci_id pci_id_qede_map[] = {
#define QEDE_RTE_PCI_DEVICE(dev) RTE_PCI_DEVICE(PCI_VENDOR_ID_QLOGIC, dev)
{
QEDE_RTE_PCI_DEVICE(PCI_DEVICE_ID_QLOGIC_NX2_57980E)
--
2.9.3
[dpdk-dev] [PATCH] crypto/qat: make PCI device id struct const
Signed-off-by: Ferruh Yigit
---
drivers/crypto/qat/rte_qat_cryptodev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/qat/rte_qat_cryptodev.c
b/drivers/crypto/qat/rte_qat_cryptodev.c
index 9594067..a492dc0 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 const struct rte_pci_id pci_id_qat_map[] = {
{
RTE_PCI_DEVICE(0x8086, 0x0443),
},
--
2.9.3
[dpdk-dev] [PATCH] devtools: add git log checks for nvm, tso, Vlan
Signed-off-by: Ferruh Yigit --- devtools/check-git-log.sh | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/devtools/check-git-log.sh b/devtools/check-git-log.sh index 62b5f43..52b8659 100755 --- a/devtools/check-git-log.sh +++ b/devtools/check-git-log.sh @@ -128,13 +128,15 @@ bad=$(echo "$headlines" | grep -E --color=always \ -e ':.*\' \ -e ':.*\' \ -e ':.*\' \ + -e ':.*\' \ -e ':.*\' \ -e ':.*\' \ -e ':.*\' \ -e ':.*\' \ -e ':.*\' \ -e ':.*\' \ - -e ':.*\' \ + -e ':.*\' \ + -e ':.*\<[Vv]lan\>' \ | sed 's,^,\t,') [ -z "$bad" ] || printf "Wrong headline lowercase:\n$bad\n" -- 2.9.3
Re: [dpdk-dev] [PATCH 1/2] mbuf: fix bitmask of Tx offload flags
On 1/24/2017 11:50 AM, Jingjing Wu wrote:
> Some Tx offload flags are missed in bitmask of all supported packet
> Tx offload features flags.
> This patch fixes it.
>
> Fixes: 4fb7e803eb1a ("ethdev: add Tx preparation")
> Signed-off-by: Jingjing Wu
Cc: Olivier MATZ
<...>
Re: [dpdk-dev] [PATCH 1/2] mbuf: fix bitmask of Tx offload flags
Hi Jingjng,
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Jingjing Wu
> Sent: Tuesday, January 24, 2017 11:48 AM
> To: dev@dpdk.org
> Cc: Wu, Jingjing
> Subject: [dpdk-dev] [PATCH 1/2] mbuf: fix bitmask of Tx offload flags
>
> Some Tx offload flags are missed in Bitmask of all supported packet
> Tx offload features flags.
> This patch fixes it.
Not sure what it exactly fixes?
As I remember these flags don't specify any TX offload for HW to perform,
But just provide information to the TX function.
Again, why only i40e code is modified?
As I remember we have the same code in other PMDs too.
Konstantin
>
> Fixes: 4fb7e803eb1a ("ethdev: add Tx preparation")
> Signed-off-by: Jingjing Wu
> ---
> lib/librte_mbuf/rte_mbuf.h | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
> index bfce9f4..e57a4d2 100644
> --- a/lib/librte_mbuf/rte_mbuf.h
> +++ b/lib/librte_mbuf/rte_mbuf.h
> @@ -295,8 +295,12 @@ extern "C" {
> */
> #define PKT_TX_OFFLOAD_MASK (\
> PKT_TX_IP_CKSUM |\
> + PKT_TX_IPV4 |\
> + PKT_TX_IPV6 |\
> PKT_TX_L4_MASK | \
> PKT_TX_OUTER_IP_CKSUM | \
> + PKT_TX_OUTER_IPV4 | \
> + PKT_TX_OUTER_IPV6 | \
> PKT_TX_TCP_SEG | \
> PKT_TX_QINQ_PKT |\
> PKT_TX_VLAN_PKT |\
> --
> 2.4.11
Re: [dpdk-dev] [PATCH 1/2] mbuf: fix bitmask of Tx offload flags
On Thu, 26 Jan 2017 14:58:08 +, "Ananyev, Konstantin"
wrote:
> Hi Jingjng,
>
> > -Original Message-
> > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Jingjing Wu
> > Sent: Tuesday, January 24, 2017 11:48 AM
> > To: dev@dpdk.org
> > Cc: Wu, Jingjing
> > Subject: [dpdk-dev] [PATCH 1/2] mbuf: fix bitmask of Tx offload
> > flags
> >
> > Some Tx offload flags are missed in Bitmask of all supported packet
> > Tx offload features flags.
> > This patch fixes it.
>
> Not sure what it exactly fixes?
> As I remember these flags don't specify any TX offload for HW to
> perform, But just provide information to the TX function.
> Again, why only i40e code is modified?
> As I remember we have the same code in other PMDs too.
> Konstantin
>
> >
> > Fixes: 4fb7e803eb1a ("ethdev: add Tx preparation")
> > Signed-off-by: Jingjing Wu
> > ---
> > lib/librte_mbuf/rte_mbuf.h | 4
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
> > index bfce9f4..e57a4d2 100644
> > --- a/lib/librte_mbuf/rte_mbuf.h
> > +++ b/lib/librte_mbuf/rte_mbuf.h
> > @@ -295,8 +295,12 @@ extern "C" {
> > */
> > #define PKT_TX_OFFLOAD_MASK (\
> > PKT_TX_IP_CKSUM |\
> > + PKT_TX_IPV4 |\
> > + PKT_TX_IPV6 |\
> > PKT_TX_L4_MASK | \
> > PKT_TX_OUTER_IP_CKSUM | \
> > + PKT_TX_OUTER_IPV4 | \
> > + PKT_TX_OUTER_IPV6 | \
> > PKT_TX_TCP_SEG | \
> > PKT_TX_QINQ_PKT |\
> > PKT_TX_VLAN_PKT |\
> > --
> > 2.4.11
>
Also, it looks like MACSEC is missing. To avoid forgetting flags in
the future, what do you think about doing the following (not tested)?
diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
index b3cccfc..aa1dc76 100644
--- a/lib/librte_mbuf/rte_mbuf.h
+++ b/lib/librte_mbuf/rte_mbuf.h
@@ -182,9 +182,11 @@ extern "C" {
*/
#define PKT_RX_TIMESTAMP (1ULL << 17)
-/* add new RX flags here */
+/* add new RX flags here, and update __PKT_RX_NEXT */
+#define __PKT_RX_NEXT(1ULL << 18)
-/* add new TX flags here */
+/* add new TX flags here, and update __PKT_TX_NEXT */
+#define __PKT_TX_NEXT(1ULL << 43)
/**
* Offload the MACsec. This flag must be set by the application to enable
@@ -295,17 +297,16 @@ extern "C" {
#define PKT_TX_OUTER_IPV6(1ULL << 60)
/**
+ * Bitmask of all supported packet Rx offload features flags,
+ * which can be set for packet.
+ */
+#define PKT_RX_OFFLOAD_MASK (__PKT_RX_NEXT - 1)
+
+/**
* Bitmask of all supported packet Tx offload features flags,
* which can be set for packet.
*/
-#define PKT_TX_OFFLOAD_MASK (\
- PKT_TX_IP_CKSUM |\
- PKT_TX_L4_MASK | \
- PKT_TX_OUTER_IP_CKSUM | \
- PKT_TX_TCP_SEG | \
- PKT_TX_QINQ_PKT |\
- PKT_TX_VLAN_PKT |\
- PKT_TX_TUNNEL_MASK)
+#define PKT_TX_OFFLOAD_MASK ((~(__PKT_TX_NEXT - 1)) & 0x1fff)
#define __RESERVED (1ULL << 61) /**< reserved for future mbuf use */
Re: [dpdk-dev] [PATCH v4 4/4] doc: describe new performance test application
On 1/25/2017 4:27 PM, Slawomir Mrozowicz wrote: > Add documentation to describe using the new performance test application. > > Signed-off-by: Slawomir Mrozowicz > Signed-off-by: Piotr Azarewicz Congratulations!, this is the 2. patch in patchwork: http://dpdk.org/dev/patchwork/patch/2/ There should be a price for the author of the each 10K. patch ;) 20.000 patches!!, good work community. (Assuming numbering started from 1 :) )
Re: [dpdk-dev] [PATCH v4 4/4] doc: describe new performance test application
> -Original Message- > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Ferruh Yigit > Sent: Thursday, January 26, 2017 3:21 PM > To: Mrozowicz, SlawomirX ; dev@dpdk.org > Cc: Azarewicz, PiotrX T ; Thomas Monjalon > > Subject: Re: [dpdk-dev] [PATCH v4 4/4] doc: describe new performance test > application > > On 1/25/2017 4:27 PM, Slawomir Mrozowicz wrote: > > Add documentation to describe using the new performance test > application. > > > > Signed-off-by: Slawomir Mrozowicz > > Signed-off-by: Piotr Azarewicz > > Congratulations!, > > this is the 2. patch in patchwork: > http://dpdk.org/dev/patchwork/patch/2/ > > There should be a price for the author of the each 10K. patch ;) > > 20.000 patches!!, good work community. > (Assuming numbering started from 1 :) ) Looks like it did. :-) Ref: http://dpdk.org/dev/patchwork/patch/1/ Accessing patch 0 gives an error. :-( /Bruce
Re: [dpdk-dev] [PATCH 1/2] mbuf: fix bitmask of Tx offload flags
Hi Olivier,
> -Original Message-
> From: Olivier MATZ [mailto:olivier.m...@6wind.com]
> Sent: Thursday, January 26, 2017 3:05 PM
> To: Ananyev, Konstantin
> Cc: Wu, Jingjing ; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 1/2] mbuf: fix bitmask of Tx offload flags
>
> On Thu, 26 Jan 2017 14:58:08 +, "Ananyev, Konstantin"
> wrote:
> > Hi Jingjng,
> >
> > > -Original Message-
> > > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Jingjing Wu
> > > Sent: Tuesday, January 24, 2017 11:48 AM
> > > To: dev@dpdk.org
> > > Cc: Wu, Jingjing
> > > Subject: [dpdk-dev] [PATCH 1/2] mbuf: fix bitmask of Tx offload
> > > flags
> > >
> > > Some Tx offload flags are missed in Bitmask of all supported packet
> > > Tx offload features flags.
> > > This patch fixes it.
> >
> > Not sure what it exactly fixes?
> > As I remember these flags don't specify any TX offload for HW to
> > perform, But just provide information to the TX function.
> > Again, why only i40e code is modified?
> > As I remember we have the same code in other PMDs too.
> > Konstantin
> >
> > >
> > > Fixes: 4fb7e803eb1a ("ethdev: add Tx preparation")
> > > Signed-off-by: Jingjing Wu
> > > ---
> > > lib/librte_mbuf/rte_mbuf.h | 4
> > > 1 file changed, 4 insertions(+)
> > >
> > > diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
> > > index bfce9f4..e57a4d2 100644
> > > --- a/lib/librte_mbuf/rte_mbuf.h
> > > +++ b/lib/librte_mbuf/rte_mbuf.h
> > > @@ -295,8 +295,12 @@ extern "C" {
> > > */
> > > #define PKT_TX_OFFLOAD_MASK (\
> > > PKT_TX_IP_CKSUM |\
> > > + PKT_TX_IPV4 |\
> > > + PKT_TX_IPV6 |\
> > > PKT_TX_L4_MASK | \
> > > PKT_TX_OUTER_IP_CKSUM | \
> > > + PKT_TX_OUTER_IPV4 | \
> > > + PKT_TX_OUTER_IPV6 | \
> > > PKT_TX_TCP_SEG | \
> > > PKT_TX_QINQ_PKT |\
> > > PKT_TX_VLAN_PKT |\
> > > --
> > > 2.4.11
> >
>
> Also, it looks like MACSEC is missing. To avoid forgetting flags in
> the future, what do you think about doing the following (not tested)?
>
>
> diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
> index b3cccfc..aa1dc76 100644
> --- a/lib/librte_mbuf/rte_mbuf.h
> +++ b/lib/librte_mbuf/rte_mbuf.h
> @@ -182,9 +182,11 @@ extern "C" {
> */
> #define PKT_RX_TIMESTAMP (1ULL << 17)
>
> -/* add new RX flags here */
> +/* add new RX flags here, and update __PKT_RX_NEXT */
> +#define __PKT_RX_NEXT(1ULL << 18)
>
> -/* add new TX flags here */
> +/* add new TX flags here, and update __PKT_TX_NEXT */
> +#define __PKT_TX_NEXT(1ULL << 43)
>
> /**
> * Offload the MACsec. This flag must be set by the application to enable
> @@ -295,17 +297,16 @@ extern "C" {
> #define PKT_TX_OUTER_IPV6(1ULL << 60)
>
> /**
> + * Bitmask of all supported packet Rx offload features flags,
> + * which can be set for packet.
> + */
> +#define PKT_RX_OFFLOAD_MASK (__PKT_RX_NEXT - 1)
> +
> +/**
> * Bitmask of all supported packet Tx offload features flags,
> * which can be set for packet.
> */
> -#define PKT_TX_OFFLOAD_MASK (\
> - PKT_TX_IP_CKSUM |\
> - PKT_TX_L4_MASK | \
> - PKT_TX_OUTER_IP_CKSUM | \
> - PKT_TX_TCP_SEG | \
> - PKT_TX_QINQ_PKT |\
> - PKT_TX_VLAN_PKT |\
> - PKT_TX_TUNNEL_MASK)
> +#define PKT_TX_OFFLOAD_MASK ((~(__PKT_TX_NEXT - 1)) & 0x1fff)
I see your point but should, let say, PKT_TX_IPV4 be part of
PKT_TX_OFFLOAD_MASK at all?
It doesn't really define any offload for PMD/HW to perform.
It just provide extra information for PMD so it can successfully process other
offload requests.
Konstantin
>
> #define __RESERVED (1ULL << 61) /**< reserved for future mbuf use
> */
>
Re: [dpdk-dev] [PATCH 1/2] mbuf: fix bitmask of Tx offload flags
On Thu, 26 Jan 2017 15:35:29 +, "Ananyev, Konstantin"
wrote:
> Hi Olivier,
>
> > -Original Message-
> > From: Olivier MATZ [mailto:olivier.m...@6wind.com]
> > Sent: Thursday, January 26, 2017 3:05 PM
> > To: Ananyev, Konstantin
> > Cc: Wu, Jingjing ; dev@dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH 1/2] mbuf: fix bitmask of Tx offload
> > flags
> >
> > On Thu, 26 Jan 2017 14:58:08 +, "Ananyev, Konstantin"
> > wrote:
> > > Hi Jingjng,
> > >
> > > > -Original Message-
> > > > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Jingjing Wu
> > > > Sent: Tuesday, January 24, 2017 11:48 AM
> > > > To: dev@dpdk.org
> > > > Cc: Wu, Jingjing
> > > > Subject: [dpdk-dev] [PATCH 1/2] mbuf: fix bitmask of Tx offload
> > > > flags
> > > >
> > > > Some Tx offload flags are missed in Bitmask of all supported
> > > > packet Tx offload features flags.
> > > > This patch fixes it.
> > >
> > > Not sure what it exactly fixes?
> > > As I remember these flags don't specify any TX offload for HW to
> > > perform, But just provide information to the TX function.
> > > Again, why only i40e code is modified?
> > > As I remember we have the same code in other PMDs too.
> > > Konstantin
> > >
> > > >
> > > > Fixes: 4fb7e803eb1a ("ethdev: add Tx preparation")
> > > > Signed-off-by: Jingjing Wu
> > > > ---
> > > > lib/librte_mbuf/rte_mbuf.h | 4
> > > > 1 file changed, 4 insertions(+)
> > > >
> > > > diff --git a/lib/librte_mbuf/rte_mbuf.h
> > > > b/lib/librte_mbuf/rte_mbuf.h index bfce9f4..e57a4d2 100644
> > > > --- a/lib/librte_mbuf/rte_mbuf.h
> > > > +++ b/lib/librte_mbuf/rte_mbuf.h
> > > > @@ -295,8 +295,12 @@ extern "C" {
> > > > */
> > > > #define PKT_TX_OFFLOAD_MASK (\
> > > > PKT_TX_IP_CKSUM |\
> > > > + PKT_TX_IPV4 |\
> > > > + PKT_TX_IPV6 |\
> > > > PKT_TX_L4_MASK | \
> > > > PKT_TX_OUTER_IP_CKSUM | \
> > > > + PKT_TX_OUTER_IPV4 | \
> > > > + PKT_TX_OUTER_IPV6 | \
> > > > PKT_TX_TCP_SEG | \
> > > > PKT_TX_QINQ_PKT |\
> > > > PKT_TX_VLAN_PKT |\
> > > > --
> > > > 2.4.11
> > >
> >
> > Also, it looks like MACSEC is missing. To avoid forgetting flags in
> > the future, what do you think about doing the following (not
> > tested)?
> >
> >
> > diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
> > index b3cccfc..aa1dc76 100644
> > --- a/lib/librte_mbuf/rte_mbuf.h
> > +++ b/lib/librte_mbuf/rte_mbuf.h
> > @@ -182,9 +182,11 @@ extern "C" {
> > */
> > #define PKT_RX_TIMESTAMP (1ULL << 17)
> >
> > -/* add new RX flags here */
> > +/* add new RX flags here, and update __PKT_RX_NEXT */
> > +#define __PKT_RX_NEXT(1ULL << 18)
> >
> > -/* add new TX flags here */
> > +/* add new TX flags here, and update __PKT_TX_NEXT */
> > +#define __PKT_TX_NEXT(1ULL << 43)
> >
> > /**
> > * Offload the MACsec. This flag must be set by the application to
> > enable @@ -295,17 +297,16 @@ extern "C" {
> > #define PKT_TX_OUTER_IPV6(1ULL << 60)
> >
> > /**
> > + * Bitmask of all supported packet Rx offload features flags,
> > + * which can be set for packet.
> > + */
> > +#define PKT_RX_OFFLOAD_MASK (__PKT_RX_NEXT - 1)
> > +
> > +/**
> > * Bitmask of all supported packet Tx offload features flags,
> > * which can be set for packet.
> > */
> > -#define PKT_TX_OFFLOAD_MASK (\
> > - PKT_TX_IP_CKSUM |\
> > - PKT_TX_L4_MASK | \
> > - PKT_TX_OUTER_IP_CKSUM | \
> > - PKT_TX_TCP_SEG | \
> > - PKT_TX_QINQ_PKT |\
> > - PKT_TX_VLAN_PKT |\
> > - PKT_TX_TUNNEL_MASK)
> > +#define PKT_TX_OFFLOAD_MASK ((~(__PKT_TX_NEXT - 1)) &
> > 0x1fff)
>
> I see your point but should, let say, PKT_TX_IPV4 be part of
> PKT_TX_OFFLOAD_MASK at all? It doesn't really define any offload for
> PMD/HW to perform. It just provide extra information for PMD so it
> can successfully process other offload requests. Konstantin
Yes, that's right. On the other hand, differentiating them may confuse
the PMD developpers (that's probably the case for this patch).
Having PKT_TX_MASK that includes all TX flags automatically would also
do the job (knowing PMDs must be updated), and would avoid to forget
flags in the future... if we decide to do it, it would be better before
17.02, because PKT_TX_OFFLOAD_MASK was added after 16.11, so it is not
yet part of the API.
In any case, we need a patch to fix the missing PKT_TX_MACSEC in
PKT_TX_OFFLOAD_MASK.
Re: [dpdk-dev] [PATCH 1/2] mbuf: fix bitmask of Tx offload flags
> -Original Message-
> From: Olivier MATZ [mailto:olivier.m...@6wind.com]
> Sent: Thursday, January 26, 2017 3:58 PM
> To: Ananyev, Konstantin
> Cc: Olivier MATZ ; Wu, Jingjing
> ; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 1/2] mbuf: fix bitmask of Tx offload flags
>
> On Thu, 26 Jan 2017 15:35:29 +, "Ananyev, Konstantin"
> wrote:
> > Hi Olivier,
> >
> > > -Original Message-
> > > From: Olivier MATZ [mailto:olivier.m...@6wind.com]
> > > Sent: Thursday, January 26, 2017 3:05 PM
> > > To: Ananyev, Konstantin
> > > Cc: Wu, Jingjing ; dev@dpdk.org
> > > Subject: Re: [dpdk-dev] [PATCH 1/2] mbuf: fix bitmask of Tx offload
> > > flags
> > >
> > > On Thu, 26 Jan 2017 14:58:08 +, "Ananyev, Konstantin"
> > > wrote:
> > > > Hi Jingjng,
> > > >
> > > > > -Original Message-
> > > > > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Jingjing Wu
> > > > > Sent: Tuesday, January 24, 2017 11:48 AM
> > > > > To: dev@dpdk.org
> > > > > Cc: Wu, Jingjing
> > > > > Subject: [dpdk-dev] [PATCH 1/2] mbuf: fix bitmask of Tx offload
> > > > > flags
> > > > >
> > > > > Some Tx offload flags are missed in Bitmask of all supported
> > > > > packet Tx offload features flags.
> > > > > This patch fixes it.
> > > >
> > > > Not sure what it exactly fixes?
> > > > As I remember these flags don't specify any TX offload for HW to
> > > > perform, But just provide information to the TX function.
> > > > Again, why only i40e code is modified?
> > > > As I remember we have the same code in other PMDs too.
> > > > Konstantin
> > > >
> > > > >
> > > > > Fixes: 4fb7e803eb1a ("ethdev: add Tx preparation")
> > > > > Signed-off-by: Jingjing Wu
> > > > > ---
> > > > > lib/librte_mbuf/rte_mbuf.h | 4
> > > > > 1 file changed, 4 insertions(+)
> > > > >
> > > > > diff --git a/lib/librte_mbuf/rte_mbuf.h
> > > > > b/lib/librte_mbuf/rte_mbuf.h index bfce9f4..e57a4d2 100644
> > > > > --- a/lib/librte_mbuf/rte_mbuf.h
> > > > > +++ b/lib/librte_mbuf/rte_mbuf.h
> > > > > @@ -295,8 +295,12 @@ extern "C" {
> > > > > */
> > > > > #define PKT_TX_OFFLOAD_MASK (\
> > > > > PKT_TX_IP_CKSUM |\
> > > > > + PKT_TX_IPV4 |\
> > > > > + PKT_TX_IPV6 |\
> > > > > PKT_TX_L4_MASK | \
> > > > > PKT_TX_OUTER_IP_CKSUM | \
> > > > > + PKT_TX_OUTER_IPV4 | \
> > > > > + PKT_TX_OUTER_IPV6 | \
> > > > > PKT_TX_TCP_SEG | \
> > > > > PKT_TX_QINQ_PKT |\
> > > > > PKT_TX_VLAN_PKT |\
> > > > > --
> > > > > 2.4.11
> > > >
> > >
> > > Also, it looks like MACSEC is missing. To avoid forgetting flags in
> > > the future, what do you think about doing the following (not
> > > tested)?
> > >
> > >
> > > diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
> > > index b3cccfc..aa1dc76 100644
> > > --- a/lib/librte_mbuf/rte_mbuf.h
> > > +++ b/lib/librte_mbuf/rte_mbuf.h
> > > @@ -182,9 +182,11 @@ extern "C" {
> > > */
> > > #define PKT_RX_TIMESTAMP (1ULL << 17)
> > >
> > > -/* add new RX flags here */
> > > +/* add new RX flags here, and update __PKT_RX_NEXT */
> > > +#define __PKT_RX_NEXT(1ULL << 18)
> > >
> > > -/* add new TX flags here */
> > > +/* add new TX flags here, and update __PKT_TX_NEXT */
> > > +#define __PKT_TX_NEXT(1ULL << 43)
> > >
> > > /**
> > > * Offload the MACsec. This flag must be set by the application to
> > > enable @@ -295,17 +297,16 @@ extern "C" {
> > > #define PKT_TX_OUTER_IPV6(1ULL << 60)
> > >
> > > /**
> > > + * Bitmask of all supported packet Rx offload features flags,
> > > + * which can be set for packet.
> > > + */
> > > +#define PKT_RX_OFFLOAD_MASK (__PKT_RX_NEXT - 1)
> > > +
> > > +/**
> > > * Bitmask of all supported packet Tx offload features flags,
> > > * which can be set for packet.
> > > */
> > > -#define PKT_TX_OFFLOAD_MASK (\
> > > - PKT_TX_IP_CKSUM |\
> > > - PKT_TX_L4_MASK | \
> > > - PKT_TX_OUTER_IP_CKSUM | \
> > > - PKT_TX_TCP_SEG | \
> > > - PKT_TX_QINQ_PKT |\
> > > - PKT_TX_VLAN_PKT |\
> > > - PKT_TX_TUNNEL_MASK)
> > > +#define PKT_TX_OFFLOAD_MASK ((~(__PKT_TX_NEXT - 1)) &
> > > 0x1fff)
> >
> > I see your point but should, let say, PKT_TX_IPV4 be part of
> > PKT_TX_OFFLOAD_MASK at all? It doesn't really define any offload for
> > PMD/HW to perform. It just provide extra information for PMD so it
> > can successfully process other offload requests. Konstantin
>
> Yes, that's right. On the other hand, differentiating them may confuse
> the PMD developpers (that's probably the case for this patch).
>
> Having PKT_TX_MASK that includes all TX flags automatically would also
> do the job (knowing PMDs must be updated),
Yes, all other PMDs that do use PKT_TX_OFFLOAD_MASK have to be
Re: [dpdk-dev] [PATCH v4 4/4] doc: describe new performance test application
2017-01-26 15:21, Ferruh Yigit: > Congratulations!, > > this is the 2. patch in patchwork: > http://dpdk.org/dev/patchwork/patch/2/ > > There should be a price for the author of the each 10K. patch ;) > > 20.000 patches!!, good work community. > (Assuming numbering started from 1 :) ) Perfect work is done in only one patch ;) +1 for congratulations!
Re: [dpdk-dev] [PATCHv6 00/33] NXP DPAA2 PMD
2017-01-26 17:48, Hemant Agrawal: > On 1/26/2017 5:25 PM, Ferruh Yigit wrote: > > On 1/23/2017 5:56 PM, Ferruh Yigit wrote: > >> I have some concerns about this PMD, > >> > >> - This is a big one, as seen above, and it is hard to review it all, I > >> don't feel confident about the amount of review done, more reviewers are > >> welcome. And we are already post RC1. > >> > >> - Although this driver introduces a new bus type, in some parts, driver > >> still has virtual devices like usage, perhaps this is not because of > >> this PMD but mostly because of overall dpdk bus structure. Still I have > >> concerns about getting driver like this, and would like to hear more > >> comments. > > > > As a result of above concerns, I propose postponing this PMD to 17.05 > > release. > > > > The dependent rte_bus just get into main repo less than two weeks ago, > > also this driver comes with a few new things first of its kind, and it > > matters to make first samples correct. > > > > I believe it is good to let the PMD be around a little more to give > > chance to both PMD and rte_bus to become more mature. > > > > I agree that this driver is coming with few new thing and it is taking > time to come up with agreeable and good solution for some of this new stuff. > > Finalizing the right framework for adding SoC based drivers took a > little longer than expected. But thanks to Thomas help in the last that > we got the basic bus framework integrated. > > Thomos- is it possible to integrate it early in 17.05 cycle, rather than > waiting till end? Yes that's a really good question. I could reword it to "when do we pull from next-* trees"? I think you and Ferruh can work to integrate it in next-net before the beginning of 17.05. So I could do a first pull of next-net when starting the 17.05 cycle. Note that 17.05 will start in few weeks.
[dpdk-dev] [PATCH] net/enic: fix MAC address add and remove
The mac_addr_add callback function was simply replacing the primary MAC
address instead of adding new ones and the mac_addr_remove callback would
only remove the primary MAC form the adapter. Fix the functions to add or
remove new address. Allow up to 64 MAC addresses per port.
Fixes: fefed3d1e62c ("enic: new driver")
Signed-off-by: John Daley
Reviewed-by: Nelson Escobar
---
drivers/net/enic/enic.h| 5 +++--
drivers/net/enic/enic_ethdev.c | 6 +++---
drivers/net/enic/enic_main.c | 21 -
3 files changed, 14 insertions(+), 18 deletions(-)
diff --git a/drivers/net/enic/enic.h b/drivers/net/enic/enic.h
index 7ff994b..a454017 100644
--- a/drivers/net/enic/enic.h
+++ b/drivers/net/enic/enic.h
@@ -60,6 +60,7 @@
#define ENIC_RQ_MAX16
#define ENIC_CQ_MAX(ENIC_WQ_MAX + (ENIC_RQ_MAX / 2))
#define ENIC_INTR_MAX (ENIC_CQ_MAX + 2)
+#define ENIC_MAX_MAC_ADDR 64
#define VLAN_ETH_HLEN 18
@@ -277,8 +278,8 @@ extern void enic_dev_stats_get(struct enic *enic,
struct rte_eth_stats *r_stats);
extern void enic_dev_stats_clear(struct enic *enic);
extern void enic_add_packet_filter(struct enic *enic);
-extern void enic_set_mac_address(struct enic *enic, uint8_t *mac_addr);
-extern void enic_del_mac_address(struct enic *enic);
+void enic_set_mac_address(struct enic *enic, uint8_t *mac_addr);
+void enic_del_mac_address(struct enic *enic, int mac_index);
extern unsigned int enic_cleanup_wq(struct enic *enic, struct vnic_wq *wq);
extern void enic_send_pkt(struct enic *enic, struct vnic_wq *wq,
struct rte_mbuf *tx_pkt, unsigned short len,
diff --git a/drivers/net/enic/enic_ethdev.c b/drivers/net/enic/enic_ethdev.c
index c3ba2aa..bffa870 100644
--- a/drivers/net/enic/enic_ethdev.c
+++ b/drivers/net/enic/enic_ethdev.c
@@ -465,7 +465,7 @@ static void enicpmd_dev_info_get(struct rte_eth_dev
*eth_dev,
device_info->max_tx_queues = enic->conf_wq_count;
device_info->min_rx_bufsize = ENIC_MIN_MTU;
device_info->max_rx_pktlen = enic->max_mtu + ETHER_HDR_LEN + 4;
- device_info->max_mac_addrs = 1;
+ device_info->max_mac_addrs = ENIC_MAX_MAC_ADDR;
device_info->rx_offload_capa =
DEV_RX_OFFLOAD_VLAN_STRIP |
DEV_RX_OFFLOAD_IPV4_CKSUM |
@@ -547,12 +547,12 @@ static void enicpmd_add_mac_addr(struct rte_eth_dev
*eth_dev,
enic_set_mac_address(enic, mac_addr->addr_bytes);
}
-static void enicpmd_remove_mac_addr(struct rte_eth_dev *eth_dev, __rte_unused
uint32_t index)
+static void enicpmd_remove_mac_addr(struct rte_eth_dev *eth_dev, uint32_t
index)
{
struct enic *enic = pmd_priv(eth_dev);
ENICPMD_FUNC_TRACE();
- enic_del_mac_address(enic);
+ enic_del_mac_address(enic, index);
}
static int enicpmd_mtu_set(struct rte_eth_dev *eth_dev, uint16_t mtu)
diff --git a/drivers/net/enic/enic_main.c b/drivers/net/enic/enic_main.c
index f0b15ac..21e8ede 100644
--- a/drivers/net/enic/enic_main.c
+++ b/drivers/net/enic/enic_main.c
@@ -190,9 +190,12 @@ void enic_dev_stats_get(struct enic *enic, struct
rte_eth_stats *r_stats)
r_stats->rx_nombuf = rte_atomic64_read(&soft_stats->rx_nombuf);
}
-void enic_del_mac_address(struct enic *enic)
+void enic_del_mac_address(struct enic *enic, int mac_index)
{
- if (vnic_dev_del_addr(enic->vdev, enic->mac_addr))
+ struct rte_eth_dev *eth_dev = enic->rte_dev;
+ uint8_t *mac_addr = eth_dev->data->mac_addrs[mac_index].addr_bytes;
+
+ if (vnic_dev_del_addr(enic->vdev, mac_addr))
dev_err(enic, "del mac addr failed\n");
}
@@ -205,15 +208,6 @@ void enic_set_mac_address(struct enic *enic, uint8_t
*mac_addr)
return;
}
- err = vnic_dev_del_addr(enic->vdev, enic->mac_addr);
- if (err) {
- dev_err(enic, "del mac addr failed\n");
- return;
- }
-
- ether_addr_copy((struct ether_addr *)mac_addr,
- (struct ether_addr *)enic->mac_addr);
-
err = vnic_dev_add_addr(enic->vdev, mac_addr);
if (err) {
dev_err(enic, "add mac addr failed\n");
@@ -1308,13 +1302,14 @@ static int enic_dev_init(struct enic *enic)
/* Get the supported filters */
enic_fdir_info(enic);
- eth_dev->data->mac_addrs = rte_zmalloc("enic_mac_addr", ETH_ALEN, 0);
+ eth_dev->data->mac_addrs = rte_zmalloc("enic_mac_addr", ETH_ALEN
+ * ENIC_MAX_MAC_ADDR, 0);
if (!eth_dev->data->mac_addrs) {
dev_err(enic, "mac addr storage alloc failed, aborting.\n");
return -1;
}
ether_addr_copy((struct ether_addr *) enic->mac_addr,
- ð_dev->data->mac_addrs[0]);
+ eth_dev->data->mac_addrs);
vnic_dev_set_reset_flag(enic->vdev, 0);
--
2.10.0
Re: [dpdk-dev] [PATCH v4 1/6] eventdev: introduce event driven programming model
> -Original Message- > From: Jerin Jacob [mailto:jerin.ja...@caviumnetworks.com] > Sent: Thursday, January 26, 2017 3:39 AM > To: Eads, Gage > Cc: Richardson, Bruce ; 'dev@dpdk.org' > ; 'thomas.monja...@6wind.com' > ; 'hemant.agra...@nxp.com' > ; Van Haaren, Harry > ; McDaniel, Timothy > > Subject: Re: [dpdk-dev] [PATCH v4 1/6] eventdev: introduce event driven > programming model > > On Wed, Jan 25, 2017 at 10:36:21PM +, Eads, Gage wrote: > > > > > > Subject: [dpdk-dev] [PATCH > > > v4 > 1/6] eventdev: introduce event driven > > programming model > > > > > > > > +/** > > + * Enqueue > > > a burst > of events objects or an event object supplied > > in > > > > > > *rte_event* > > + * structure on an event device designated > > > by its > *dev_id* > > through the event + * port specified by > > > *port_id*. Each > event > > object specifies the event queue on + > > > * which it will be > enqueued. > > > > > > + * > > > > > > + * The *nb_events* parameter is the number of event > > > objects to > > > enqueue which are + * supplied in the *ev* array > > > of *rte_event* > > > structure. > > > > > > + * > > > > > > + * The rte_event_enqueue_burst() function returns the > > > number of > + > > * events objects it actually enqueued. A return > > > value equal to > > > *nb_events* + * means that all event objects have > been enqueued. > > > > > > + * > > > > > > + * @param dev_id > > > > > > + * The identifier of the device. > > > > > > + * @param port_id > > > > > > + * The identifier of the event port. > > > > > > + * @param ev > > > > > > + * Points to an array of *nb_events* objects of type > *rte_event* > > > > > structure > > > > > > + * which contain the event object enqueue operations to be > > > > > processed. > > > > > > + * @param nb_events > > > > > > + * The number of event objects to enqueue, typically number > of > > > > > > + * rte_event_port_enqueue_depth() available for this port. > > > > > > + * > > > > > > + * @return > > > > > > + * The number of event objects actually enqueued on the event > > > > > device. The > > > > > > + * return value can be less than the value of the *nb_events* > > > > > parameter > > > > > > when > > > > > > + * the event devices queue is full or if invalid parameters > are > > > > > specified in a > > > > > > + * *rte_event*. If return value is less than *nb_events*, the > > > > > remaining events > > > > > > + * at the end of ev[] are not consumed,and the caller has to > take > > > > > care of > > > > > > them > > > > > > + * > > > > > > + * @see rte_event_port_enqueue_depth() + */ +uint16_t > > > > > > +rte_event_enqueue_burst(uint8_t dev_id, uint8_t port_id, > > > > > > + const struct rte_event ev[], uint16_t > nb_events); > > > > > > > > > > There are a number of reasons this operation could fail to > > > enqueue > all > the events, including: > > > > > - Backpressure > > > > > - Invalid port ID > > > > > - Invalid queue ID > > > > > - Invalid sched type when a queue is configured for > > > ATOMIC_ONLY, > > ORDERED_ONLY, or PARALLEL_ONLY > - ... > > > > > > > > > > The current API doesn't provide a straightforward way to > > > determine > the > cause of a failure. This is a particular issue > > > on event PMDs > that can > backpressure, where the app may want to > > > treat that case > differently > than the other failure cases. > > > > > > > > > > Could we change the return type to int16_t, and define a set > > > of > error > cases (e.g. -ENOSPC for backpressure, -EINVAL for an > > > invalid argument)? > > > > > (With corresponding changes needed in the PMD API) Similarly > > > we > could > change rte_event_dequeue_burst() to return an > > > int16_t, with > -EINVAL as > a possible error case. > > > > > > > > Use rte_errno instead, I suggest. That's what it's there for. > > > > > > > > /Bruce > > > > > > That makes sense. In that case, the API comment could be tweaked like > so: > > > > > >* If the return value is less than *nb_events*, the remaining events > at the > > >* end of ev[] are not consumed and the caller has to take care of > them, > and > > >* rte_errno is set accordingly. Possible errno values include: > > >* - EINVAL - The port ID is invalid, an event's queue ID is invalid, > or an > > >*event's sched type doesn't match the capabilities of the > > >*destination queue. > > >* - ENOSPC - The event port was backpressured and unable to enqueue > one or > > >*more events. > > > > However it seems better to use a signed integer for the dequeue burst > return > value, if it is to use rte_errno. Application code could be simplified: > > > > (
[dpdk-dev] technical board meeting minutes 2017-01-25
There was a DPDK technical board meeting yesterday. The goal was to reply questions asked recently in the community. Most of them originate from the meetings about moving to Linux Foundation. Here are the minutes. * Should we change the size of the tech board? Yes we must increase the number of members to have a better representation of the community. It is reminded that board positions are held by individuals, not companies. Members can move to a new company and keep their seat as long as they are actively involved in the community. * Should we remove some members? Panu Matilainen resigned because he is not involved anymore. This is different of a removal by the board. However, we must define the removal process. Here it is: It can be decided to remove a member if there is an approval of 2/3 of the whole technical board. It can be decided either to replace the member, or to redefine the size of the board. * Should we add new members? The Linux Foundation draft charter specifies that employees of a single company should not occupy more than 50% of board seats. The technical board feels that this should be reduced to 40%. So with a board of 8 or 9 members, the maximum for any company is 3. We have chosen (with global consensus) 3 new members to join the technical board. They will be announced soon when we will have their agreement. The new board will probably count 9 members. * Should we have a process to renew the board? There will be some renewal when it will be felt as needed. We would like to open a session at the next userspace meeting to get some feedbacks about the composition of the technical board, and more generally about its role. This annual session at the userspace meeting might be the opportunity to vote for the composition of the technical board. * Should we have regular meetings? We do not want to spend too many time in meetings. However a short meeting (less than a hour) every two weeks may be relevant. * What could be discussed at regular meetings? Any contributor can ask to add a topic in the agenda by sending an email to techbo...@dpdk.org. The board members will add any topic of interest in the agenda. If a technical discussion lacks of explanation, details or evidence, it will be asked on the mailing list. If a patch does not receive any or enough comment, we will help to make it progressing on the mailing list. If there is no consensus in a discussion, a decision can be taken by the technical board and explained on the mailing list. If there is nothing to discuss, the meeting will be hopefully really short. * Should we organize regular public IRC meetings? It does not scale to have too many participants in a meeting. In order to keep meetings short, they will be private. Everybody can discuss on the mailing list. * How to report the meeting minutes? The meetings happen on IRC and may use voice if needed. The role of meeting leader - whose role involves taking the meeting minutes - will be rotated among the members so as to share the workload. Minutes will be sent to dev@dpdk.org so anyone can comment. However, the technical discussions should happen in the original thread. Feel free to comment. The next meeting should happen in less than three weeks.
[dpdk-dev] [PATCH] vfio: fix file descriptor leak in multi-process applications
When a secondary process wants access to the VFIO container file
descriptor, the primary process calls vfio_get_container_fd() which
always opens an entirely new file descriptor on /dev/vfio/vfio.
However, once the file descriptor has been passed to the subprocess, it
is effectively duplicated, meaning that the copy of the file descriptor
in the primary process is no longer needed. However, the primary
process does not close the duplicate fd, which results in a resource
leak.
This can be reproduced by starting a primary process with a small
RLIMIT_NOFILE limit configured to use VFIO for at least one device, and
repeatedly launching secondary processes until the file descriptor limit
is exceeded.
Fix the resource leak by closing the local vfio container file
descriptor after passing it to the secondary process.
Fixes: 2f4adfad0a69 ("vfio: add multiprocess support")
Signed-off-by: Patrick MacArthur
---
lib/librte_eal/linuxapp/eal/eal_vfio_mp_sync.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/librte_eal/linuxapp/eal/eal_vfio_mp_sync.c
b/lib/librte_eal/linuxapp/eal/eal_vfio_mp_sync.c
index 00cf919b64d0..fb4a2f84b180 100644
--- a/lib/librte_eal/linuxapp/eal/eal_vfio_mp_sync.c
+++ b/lib/librte_eal/linuxapp/eal/eal_vfio_mp_sync.c
@@ -301,6 +301,7 @@ vfio_mp_sync_thread(void __rte_unused * arg)
vfio_mp_sync_send_request(conn_sock,
SOCKET_ERR);
else
vfio_mp_sync_send_fd(conn_sock, fd);
+ close(fd);
break;
case SOCKET_REQ_GROUP:
/* wait for group number */
--
2.9.3
Re: [dpdk-dev] technical board meeting minutes 2017-01-25
Comments inline below. Jim -Original Message- From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Thomas Monjalon Sent: Thursday, January 26, 2017 3:14 PM To: dev@dpdk.org Cc: techbo...@dpdk.org Subject: [dpdk-dev] technical board meeting minutes 2017-01-25 There was a DPDK technical board meeting yesterday. The goal was to reply questions asked recently in the community. Most of them originate from the meetings about moving to Linux Foundation. Here are the minutes. * Should we change the size of the tech board? Yes we must increase the number of members to have a better representation of the community. It is reminded that board positions are held by individuals, not companies. Members can move to a new company and keep their seat as long as they are actively involved in the community. * Should we remove some members? Panu Matilainen resigned because he is not involved anymore. This is different of a removal by the board. However, we must define the removal process. Here it is: It can be decided to remove a member if there is an approval of 2/3 of the whole technical board. It can be decided either to replace the member, or to redefine the size of the board. [>] Did you decide how the discussion or topic to remove a board member ever even comes up to begin with? [>] For example, does someone propose "I think we should remove so-and-so from the TSC/TechBoard" and then the board votes? I think this step will be very rare (maybe never), but it's important to know how/when the removal process can be initiated and if limited by who? (e.g. can anyone in the community suggest to remove someone? Can only TechBoard/TSC members suggest to remove someone? What board member behavior would justify removal?) * Should we add new members? The Linux Foundation draft charter specifies that employees of a single company should not occupy more than 50% of board seats. The technical board feels that this should be reduced to 40%. So with a board of 8 or 9 members, the maximum for any company is 3. We have chosen (with global consensus) 3 new members to join the technical board. They will be announced soon when we will have their agreement. The new board will probably count 9 members. [>] What is the delay in announcing the new members? Does "global consensus" mean within the globe or world of just the TechBoard/TSC members, e.g. it needs to be a unanimous vote by the TSC members? Is this 100% global consensus/unanimous decision process what will be used in the future? If that's the case, what happens if 5 members say yes and 4 say no? The candidate is then not added as a new TSC member? * Should we have a process to renew the board? There will be some renewal when it will be felt as needed. We would like to open a session at the next userspace meeting to get some feedbacks about the composition of the technical board, and more generally about its role. This annual session at the userspace meeting might be the opportunity to vote for the composition of the technical board. [>] Not to be flippant, but the LF governance discussion and especially budget includes line items for funding events such as DPDK Summit Userspace. But if we can't get a point of agreement on the budget, get to an agreement on membership fees, and recruit enough member companies to the project, then future events will be dependent on our ability to raise sponsorship funds across the community. Efforts to do this in the past have only shown support from Intel, Red Hat, and Cisco. No other company has yet agreed to help financially sponsor any of the Summit events. * Should we have regular meetings? We do not want to spend too many time in meetings. However a short meeting (less than a hour) every two weeks may be relevant. [>] I assume you are referring solely to the TechBoard/TSC meeting. * What could be discussed at regular meetings? Any contributor can ask to add a topic in the agenda by sending an email to techbo...@dpdk.org. The board members will add any topic of interest in the agenda. If a technical discussion lacks of explanation, details or evidence, it will be asked on the mailing list. If a patch does not receive any or enough comment, we will help to make it progressing on the mailing list. If there is no consensus in a discussion, a decision can be taken by the technical board and explained on the mailing list. If there is nothing to discuss, the meeting will be hopefully really short. * Should we organize regular public IRC meetings? It does not scale to have too many participants in a meeting. In order to keep meetings short, they will be private. Everybody can discuss on the mailing list. [>] Are you referring to TSC/TechBoard meetings here too? Or are you referring to regular community calls? If community calls, I disagree and believe there should be a regular community project call to discuss any/all issues. Items that go back and forth many times on the mailing list could be resolved i
Re: [dpdk-dev] [PATCH] drivers/net: make PCI device id struct const
On Thursday 26 January 2017 07:37 PM, Ferruh Yigit wrote: Signed-off-by: Ferruh Yigit --- drivers/net/bnx2x/bnx2x_ethdev.c | 4 ++-- drivers/net/bnxt/bnxt_ethdev.c | 2 +- drivers/net/cxgbe/cxgbe_ethdev.c | 2 +- drivers/net/ena/ena_ethdev.c | 2 +- drivers/net/nfp/nfp_net.c| 2 +- drivers/net/qede/qede_ethdev.c | 4 ++-- 6 files changed, 8 insertions(+), 8 deletions(-) Do you think making this change in test_pci.c also makes sense? Either way: Acked-by: Shreyansh Jain
Re: [dpdk-dev] [PATCH] crypto/qat: make PCI device id struct const
On Thursday 26 January 2017 07:37 PM, Ferruh Yigit wrote:
Signed-off-by: Ferruh Yigit
---
drivers/crypto/qat/rte_qat_cryptodev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/qat/rte_qat_cryptodev.c
b/drivers/crypto/qat/rte_qat_cryptodev.c
index 9594067..a492dc0 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 const struct rte_pci_id pci_id_qat_map[] = {
{
RTE_PCI_DEVICE(0x8086, 0x0443),
},
Acked-by: Shreyansh Jain
Re: [dpdk-dev] Understanding of Acked-By
On Wednesday 25 January 2017 08:28 PM, Thomas Monjalon wrote: 2017-01-25 13:53, Van Haaren, Harry: There was an idea (from Thomas) to better document the Acked-by and Reviewed-By in the above thread, which I think is worth doing to make the process clearer. I'll kick off a thread*, and offer to submit a patch for the documentation when a consensus is reached. The question that needs to be addressed is "What is the most powerful signoff to add as somebody who checked a patch?" I do not see the benefit of knowing the most powerful. Anyway, the most powerful tags are done by trusted people. And people are trusted after delivering good reviews or patches ;) The question should be "How to use the tags?" The documentation mentions Acked, Reviewed, and Tested by[1], as signoffs that can be commented on patches. The Review Process[2] section mentions Reviewed and Tested by, but nowhere specifically states what any of these indicate. Offered below is my current understanding of the Acked-by; Reviewed-by; and Tested-by tags, in order of least-powerful first: 3) Tested-by: (least powerful) - Indicates having passed testing of functionality, and works as expected for Tester - Does NOT include full code review (instead use Reviewed by) - Does NOT indicate that the Tester understands architecture (instead use Acked by) 2) Reviewed-by: - Indicates having passed code-review, checkpatch and compilation testing by Reviewer Compilation testing is done by the CI. The reviewer must just check the results. - Does NOT include full testing of functionality (instead use Tested-by) - Does NOT indicate that the Reviewer understands architecture (instead use Acked by) I disagree here. The reviewer must understand the impacts of the patch. That's why a Reviewed-by tag is really strong. From what I understand, 'Reviewed-by' and 'Acked-by' are the other way around. - Acked-by is intent that 'I agree with change'. - Reviewed-by is 'I vouch for the changes' either through review or testing or both. 1) Acked-by: (most powerful) - Indicates Reviewed-by, but also: A maintainer may want to approve the intent without doing a full review, especially if he trusts the author or the reviewers. That's why I think Acked-by should not include Reviewed-by. If a maintainer does a full review, he should use Reviewed-by instead of Acked-by. - Acker understands impact to architecture (if any) and agrees with changes - Acker has performed runtime sanity check Not sure about this one. Personnaly I give some Acks without testing sometimes. We may add a Tested-by to indicate we made some tests. - Requests "please merge" to maintainer Yes, "please merge" to tree maintainer (committer). - Level of trust in Acked-by based on previous contributions to DPDK/networking community The level of trust applies to any tag or comment. The above is a suggested interpretation, alternative interpretations welcomed. Thanks Harry
