[dpdk-dev] [PATCH] eal/linux: fix negative value for undetermined numa_node
I asked about this many months ago and was informed that "-1" is a "standard error value" that I should expect from these APIs when NUMA is not present. Now we're saying I have to change my code again to handle a zero value? Also not sure how to tell the difference between no NUMA, something running on socket zero, and something with multiple sockets. Seems like we need a bit of thought about how the NUMA APIs should behave overall. Matthew. On Fri, Jul 31, 2015 at 09:36:12AM +0800, Cunming Liang wrote: > The patch sets zero as the default value of pci device numa_node > if the socket could not be determined. > It provides the same default value as FreeBSD which has no NUMA support, > and makes the return value of rte_eth_dev_socket_id() be consistent > with the API description. > > Signed-off-by: Cunming Liang
[dpdk-dev] [PATCH v3] doc: announce abi change for interrupt mode
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Cunming Liang > Sent: Wednesday, July 29, 2015 10:05 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH v3] doc: announce abi change for interrupt mode > > The patch announces the planned ABI changes for interrupt mode. > > Signed-off-by: Cunming Liang Acked-by: Helin Zhang
[dpdk-dev] [PATCH] e1000: fix ieee1588 timestamp issue
Hi John, > -Original Message- > From: Mcnamara, John > Sent: Thursday, July 30, 2015 5:59 PM > To: Lu, Wenzhuo; dev at dpdk.org > Subject: RE: [dpdk-dev] [PATCH] e1000: fix ieee1588 timestamp issue > > > -Original Message- > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Wenzhuo Lu > > Sent: Thursday, July 30, 2015 9:34 AM > > To: dev at dpdk.org > > Subject: [dpdk-dev] [PATCH] e1000: fix ieee1588 timestamp issue > > > > Ieee1588 reads system time to set its timestamp. On 1G NICs, for > > example, i350, system time is disabled by default. It means the > > ieee1588 timestamp will always be 0. > > This patch enables system time when ieee1588 is enabled. > > Looks good. > > > > +#define E1000_TSAUXC_DISABLE_SYSTIME 0x8000 > > Probably best to move this to the top of the file with the other timesync > defines. Thanks for looking into this. I'll send a V2. > > > I wonder if this would also fix the following known issue with i210 > timesyncing > from the release notes: > > http://dpdk.org/doc/guides/rel_notes/known_issues.html#ieee1588-support- > possibly-not-working-with-an-intel-ethernet-controller-i210-nic > > I don't have an i210 NIC to test but perhaps someone could verify it. > > John
[dpdk-dev] [PATCH v2] e1000: fix ieee1588 timestamp issue
Ieee1588 reads system time to set its timestamp. On 1G NICs, for example,
i350, system time is disabled by default. It means the ieee1588 timestamp
will always be 0.
This patch enables system time when ieee1588 is enabled.
v2 changes:
* move the macro to the top of the file with the other timesync defines.
Signed-off-by: Wenzhuo Lu
---
drivers/net/e1000/igb_ethdev.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/net/e1000/igb_ethdev.c b/drivers/net/e1000/igb_ethdev.c
index 56734a3..b2f57c4 100644
--- a/drivers/net/e1000/igb_ethdev.c
+++ b/drivers/net/e1000/igb_ethdev.c
@@ -82,6 +82,7 @@
#define E1000_TIMINCA_INCVALUE 1600
#define E1000_TIMINCA_INIT ((0x02 << E1000_TIMINCA_16NS_SHIFT) \
| E1000_TIMINCA_INCVALUE)
+#define E1000_TSAUXC_DISABLE_SYSTIME 0x8000
static int eth_igb_configure(struct rte_eth_dev *dev);
static int eth_igb_start(struct rte_eth_dev *dev);
@@ -3903,6 +3904,12 @@ igb_timesync_enable(struct rte_eth_dev *dev)
{
struct e1000_hw *hw = E1000_DEV_PRIVATE_TO_HW(dev->data->dev_private);
uint32_t tsync_ctl;
+ uint32_t tsauxc;
+
+ /* Enable system time for it isn't on by default. */
+ tsauxc = E1000_READ_REG(hw, E1000_TSAUXC);
+ tsauxc &= ~E1000_TSAUXC_DISABLE_SYSTIME;
+ E1000_WRITE_REG(hw, E1000_TSAUXC, tsauxc);
/* Start incrementing the register used to timestamp PTP packets. */
E1000_WRITE_REG(hw, E1000_TIMINCA, E1000_TIMINCA_INIT);
--
1.9.3
[dpdk-dev] [PATCH] eal/linux: fix negative value for undetermined numa_node
The patch sets zero as the default value of pci device numa_node
if the socket could not be determined.
It provides the same default value as FreeBSD which has no NUMA support,
and makes the return value of rte_eth_dev_socket_id() be consistent
with the API description.
Signed-off-by: Cunming Liang
---
lib/librte_eal/linuxapp/eal/eal_pci.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/librte_eal/linuxapp/eal/eal_pci.c
b/lib/librte_eal/linuxapp/eal/eal_pci.c
index 0e62f65..f573092 100644
--- a/lib/librte_eal/linuxapp/eal/eal_pci.c
+++ b/lib/librte_eal/linuxapp/eal/eal_pci.c
@@ -325,8 +325,8 @@ pci_scan_one(const char *dirname, uint16_t domain, uint8_t
bus,
snprintf(filename, sizeof(filename), "%s/numa_node",
dirname);
if (access(filename, R_OK) != 0) {
- /* if no NUMA support just set node to -1 */
- dev->numa_node = -1;
+ /* if no NUMA support, set default to 0 */
+ dev->numa_node = 0;
} else {
if (eal_parse_sysfs_value(filename, &tmp) < 0) {
free(dev);
--
2.4.3
[dpdk-dev] [PATCH] fm10k: fix 2 bugs in rxtx_queue_disable and fm10k_dev_start
In Rx and Tx queue_disable functions, the index of queue should
be qnum other than i which is the iteration of time expiration.
When a Tx queue fails to start in fm10k_dev_start, all Rx queues
and Tx queues that are started should be cleaned before the
function returns an error.
Signed-off-by: Wang Xiao W
---
drivers/net/fm10k/fm10k_ethdev.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/net/fm10k/fm10k_ethdev.c b/drivers/net/fm10k/fm10k_ethdev.c
index 902ccae..35f34bb 100644
--- a/drivers/net/fm10k/fm10k_ethdev.c
+++ b/drivers/net/fm10k/fm10k_ethdev.c
@@ -180,7 +180,7 @@ rx_queue_disable(struct fm10k_hw *hw, uint16_t qnum)
/* Wait 100us at most */
for (i = 0; i < FM10K_QUEUE_DISABLE_TIMEOUT; i++) {
rte_delay_us(1);
- reg = FM10K_READ_REG(hw, FM10K_RXQCTL(i));
+ reg = FM10K_READ_REG(hw, FM10K_RXQCTL(qnum));
if (!(reg & FM10K_RXQCTL_ENABLE))
break;
}
@@ -269,7 +269,7 @@ tx_queue_disable(struct fm10k_hw *hw, uint16_t qnum)
/* Wait 100us at most */
for (i = 0; i < FM10K_QUEUE_DISABLE_TIMEOUT; i++) {
rte_delay_us(1);
- reg = FM10K_READ_REG(hw, FM10K_TXDCTL(i));
+ reg = FM10K_READ_REG(hw, FM10K_TXDCTL(qnum));
if (!(reg & FM10K_TXDCTL_ENABLE))
break;
}
@@ -784,6 +784,9 @@ fm10k_dev_start(struct rte_eth_dev *dev)
diag = fm10k_dev_tx_queue_start(dev, i);
if (diag != 0) {
int j;
+ for (j = 0; j < i; ++j)
+ tx_queue_clean(dev->data->tx_queues[j]);
+
for (j = 0; j < dev->data->nb_rx_queues; ++j)
rx_queue_clean(dev->data->rx_queues[j]);
return diag;
--
1.9.3
[dpdk-dev] [PATCH] fm10k: fix 2 bugs in rxtx_queue_disable and fm10k_dev_start
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Wang Xiao W > Sent: Friday, July 31, 2015 1:06 PM > To: dev at dpdk.org > Cc: Wang, Xiao W > Subject: [dpdk-dev] [PATCH] fm10k: fix 2 bugs in rxtx_queue_disable and > fm10k_dev_start > > In Rx and Tx queue_disable functions, the index of queue should > be qnum other than i which is the iteration of time expiration. > When a Tx queue fails to start in fm10k_dev_start, all Rx queues > and Tx queues that are started should be cleaned before the > function returns an error. > > Signed-off-by: Wang Xiao W Acked-by: Jing Chen
[dpdk-dev] [PATCH v2] e1000: fix ieee1588 timestamp issue
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Wenzhuo Lu > Sent: Friday, July 31, 2015 2:21 AM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH v2] e1000: fix ieee1588 timestamp issue > > Ieee1588 reads system time to set its timestamp. On 1G NICs, for example, > i350, system time is disabled by default. It means the ieee1588 timestamp > will always be 0. > This patch enables system time when ieee1588 is enabled. > > v2 changes: > * move the macro to the top of the file with the other timesync defines. > > Signed-off-by: Wenzhuo Lu Acked-by: John McNamara
[dpdk-dev] Fwd: OVS with DPDK ..Error packets
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Srikanth Akula
> Sent: Wednesday, July 29, 2015 10:32 PM
> To: dev at dpdk.org; dev at openvswitch.org
> Subject: [dpdk-dev] Fwd: OVS with DPDK ..Error packets
>
> (+DPDK dev team )
>
>
> Hello ,
>
> I am trying to test the OVS_DPDK performance and found that lot of packets
> being treated as error packets .
>
> ovs-vsctl get Interface dpdk0 statistics
> {collisions=0, rx_bytes=38915076374, rx_crc_err=0, rx_dropped=0,
> *rx_errors=3840287219
> <3840287219>, *rx_frame_err=0, rx_over_err=0, rx_packets=292972799,
> tx_bytes=38935883904, tx_dropped=0, tx_errors=0, tx_packets=293068162}
>
> I am running DPDK application inside my VM .
>
> Looks like there is a buffer issue ( 64Bytes - 10Gbps)
>
> Could somebody let me know if i have missed any configuration in DPDK/OVS ?
Errors can show here when you are sending traffic in at a rate higher than can
be handled, so it can be normal to see that in some cases.
First thing I would check is that you have your PMD(s) and qemu threads doing
the fwding core affinitised to different cores so they get the max amount of
cycles they can.
I would also check a simple phy-phy test to eliminate any test equipment/NIC
setup issues.
>
> -Srikanth
[dpdk-dev] [PATCH v1] ixgbe: remove vector pmd burst size restriction
The patch removes the restriction of burst size on a constant 32.
On receive side, the burst size floor now aligns to RTE_IXGBE_DESCS_PER_LOOP
power of 2.
According to this rule, the burst size less than 4 still won't receive anything.
(Before this change, the burst size less than 32 can't receive anything.)
On transmit side, the max burst size no longer bind with a constant, however it
still
require to check the cross tx_rs_thresh violation.
There's no obvious performance drop found on both recv_pkts_vec
and recv_scattered_pkts_vec on burst size 32.
Signed-off-by: Cunming Liang
---
drivers/net/ixgbe/ixgbe_rxtx.c | 3 ++-
drivers/net/ixgbe/ixgbe_rxtx.h | 4 +---
drivers/net/ixgbe/ixgbe_rxtx_vec.c | 35 ---
3 files changed, 19 insertions(+), 23 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_rxtx.c b/drivers/net/ixgbe/ixgbe_rxtx.c
index 3f808b3..dbdb761 100644
--- a/drivers/net/ixgbe/ixgbe_rxtx.c
+++ b/drivers/net/ixgbe/ixgbe_rxtx.c
@@ -4008,7 +4008,8 @@ ixgbe_set_rx_function(struct rte_eth_dev *dev)
*/
} else if (adapter->rx_vec_allowed) {
PMD_INIT_LOG(DEBUG, "Vector rx enabled, please make sure RX "
- "burst size no less than 32.");
+ "burst size no less than 4 (port=%d).",
+dev->data->port_id);
dev->rx_pkt_burst = ixgbe_recv_pkts_vec;
} else if (adapter->rx_bulk_alloc_allowed) {
diff --git a/drivers/net/ixgbe/ixgbe_rxtx.h b/drivers/net/ixgbe/ixgbe_rxtx.h
index 113682a..eb931fe 100644
--- a/drivers/net/ixgbe/ixgbe_rxtx.h
+++ b/drivers/net/ixgbe/ixgbe_rxtx.h
@@ -47,9 +47,7 @@
(uint64_t) ((mb)->buf_physaddr + RTE_PKTMBUF_HEADROOM)
#ifdef RTE_IXGBE_INC_VECTOR
-#define RTE_IXGBE_VPMD_RX_BURST 32
-#define RTE_IXGBE_VPMD_TX_BURST 32
-#define RTE_IXGBE_RXQ_REARM_THRESH RTE_IXGBE_VPMD_RX_BURST
+#define RTE_IXGBE_RXQ_REARM_THRESH 32
#define RTE_IXGBE_TX_MAX_FREE_BUF_SZ64
#endif
diff --git a/drivers/net/ixgbe/ixgbe_rxtx_vec.c
b/drivers/net/ixgbe/ixgbe_rxtx_vec.c
index 1c16dec..b72f817 100644
--- a/drivers/net/ixgbe/ixgbe_rxtx_vec.c
+++ b/drivers/net/ixgbe/ixgbe_rxtx_vec.c
@@ -199,13 +199,11 @@ desc_to_olflags_v(__m128i descs[4], struct rte_mbuf
**rx_pkts)
#endif
/*
- * vPMD receive routine, now only accept (nb_pkts == RTE_IXGBE_VPMD_RX_BURST)
- * in one loop
+ * vPMD raw receive routine
*
* Notice:
- * - nb_pkts < RTE_IXGBE_VPMD_RX_BURST, just return no packet
- * - nb_pkts > RTE_IXGBE_VPMD_RX_BURST, only scan RTE_IXGBE_VPMD_RX_BURST
- * numbers of DD bit
+ * - floor align nb_pkts to a RTE_IXGBE_DESC_PER_LOOP power-of-two
+ * - 'nb_pkts < 4' causes 0 packet receiving
* - don't support ol_flags for rss and csum err
*/
static inline uint16_t
@@ -240,8 +238,7 @@ _recv_raw_pkts_vec(struct ixgbe_rx_queue *rxq, struct
rte_mbuf **rx_pkts,
__m128i dd_check, eop_check;
#endif /* RTE_NEXT_ABI */
- if (unlikely(nb_pkts < RTE_IXGBE_VPMD_RX_BURST))
- return 0;
+ nb_pkts = RTE_ALIGN_FLOOR(nb_pkts, RTE_IXGBE_DESCS_PER_LOOP);
/* Just the act of getting into the function from the application is
* going to cost about 7 cycles */
@@ -310,7 +307,7 @@ _recv_raw_pkts_vec(struct ixgbe_rx_queue *rxq, struct
rte_mbuf **rx_pkts,
* D. fill info. from desc to mbuf
*/
#endif /* RTE_NEXT_ABI */
- for (pos = 0, nb_pkts_recd = 0; pos < RTE_IXGBE_VPMD_RX_BURST;
+ for (pos = 0, nb_pkts_recd = 0; pos < nb_pkts;
pos += RTE_IXGBE_DESCS_PER_LOOP,
rxdp += RTE_IXGBE_DESCS_PER_LOOP) {
__m128i descs[RTE_IXGBE_DESCS_PER_LOOP];
@@ -450,13 +447,11 @@ _recv_raw_pkts_vec(struct ixgbe_rx_queue *rxq, struct
rte_mbuf **rx_pkts,
}
/*
- * vPMD receive routine, now only accept (nb_pkts == RTE_IXGBE_VPMD_RX_BURST)
- * in one loop
+ * vPMD receive routine
*
* Notice:
- * - nb_pkts < RTE_IXGBE_VPMD_RX_BURST, just return no packet
- * - nb_pkts > RTE_IXGBE_VPMD_RX_BURST, only scan RTE_IXGBE_VPMD_RX_BURST
- * numbers of DD bit
+ * - floor align nb_pkts to a RTE_IXGBE_DESC_PER_LOOP power-of-two
+ * - 'nb_pkts < 4' causes 0 packet receiving
* - don't support ol_flags for rss and csum err
*/
uint16_t
@@ -470,12 +465,11 @@ static inline uint16_t
reassemble_packets(struct ixgbe_rx_queue *rxq, struct rte_mbuf **rx_bufs,
uint16_t nb_bufs, uint8_t *split_flags)
{
- struct rte_mbuf *pkts[RTE_IXGBE_VPMD_RX_BURST]; /*finished pkts*/
+ struct rte_mbuf *pkts[nb_bufs]; /*finished pkts*/
struct rte_mbuf *start = rxq->pkt_first_seg;
struct rte_mbuf *end = rxq->pkt_last_seg;
unsigned pkt_idx, buf_idx;
-
for (buf_idx = 0, pkt_idx = 0; buf_idx < nb_bufs; buf_idx++) {
if (end != NULL) {
/* processing a split packet */
@@ -535,14 +529,17 @@ reassemble_packets(struct i
[dpdk-dev] [PATCH] ethdev: fix ABI breakage in lro code
> -Original Message-
> From: Neil Horman [mailto:nhorman at tuxdriver.com]
> Sent: Monday, July 13, 2015 3:00 PM
> To: Mcnamara, John
> Cc: dev at dpdk.org; vladz at cloudius-systems.com
> Subject: Re: [dpdk-dev] [PATCH] ethdev: fix ABI breakage in lro code
>
> On Mon, Jul 13, 2015 at 10:47:03AM +, Mcnamara, John wrote:
> > > -Original Message-
> > > From: Neil Horman [mailto:nhorman at tuxdriver.com]
> > > Sent: Monday, July 13, 2015 11:42 AM
> > > To: Mcnamara, John
> > > Cc: dev at dpdk.org; vladz at cloudius-systems.com
> > > Subject: Re: [dpdk-dev] [PATCH] ethdev: fix ABI breakage in lro code
> > >
> > > On Mon, Jul 13, 2015 at 11:26:25AM +0100, John McNamara wrote:
> > > > Fix for ABI breakage introduced in LRO addition. Moves lro
> > > > bitfield to the end of the struct/member.
> > > >
> > > > Fixes: 8eecb3295aed (ixgbe: add LRO support)
> > > >
> > > > Signed-off-by: John McNamara
> > > > ---
> > > > lib/librte_ether/rte_ethdev.h | 4 ++--
> > > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/lib/librte_ether/rte_ethdev.h
> > > > b/lib/librte_ether/rte_ethdev.h index 79bde89..1c3ace1 100644
> > > > --- a/lib/librte_ether/rte_ethdev.h
> > > > +++ b/lib/librte_ether/rte_ethdev.h
> > > > @@ -1578,9 +1578,9 @@ struct rte_eth_dev_data {
> > > > uint8_t port_id; /**< Device [external] port
> identifier.
> > > */
> > > > uint8_t promiscuous : 1, /**< RX promiscuous mode ON(1) /
> OFF(0).
> > > */
> > > > scattered_rx : 1, /**< RX of scattered packets is ON(1)
> /
> > > OFF(0) */
> > > > - lro : 1, /**< RX LRO is ON(1) / OFF(0) */
> > > > all_multicast : 1, /**< RX all multicast mode ON(1) /
> OFF(0).
> > > */
> > > > - dev_started : 1; /**< Device state: STARTED(1) /
> STOPPED(0).
> > > */
> > > > + dev_started : 1, /**< Device state: STARTED(1) /
> STOPPED(0).
> > > */
> > > > + lro : 1; /**< RX LRO is ON(1) / OFF(0) */
> > > > };
> > > >
> > > > /**
> > > > --
> > > > 1.8.1.4
> > > >
> > > >
> > > I presume the ABI checker stopped complaining about this with the
> > > patch, yes?
> >
> > Hi Neil,
> >
> > Yes, I replied about that in the previous thread.
> >
> Thank you, I'll ack as soon as Chao confirms its not a problem on ppc Neil
Hi Chao,
Any reply on this.
Neil, if there is no reply to this from the PPC maintainer do you have any
objection to this going in as is.
It at least fixes the LRO ABI breakage on the platforms we can test on.
John
[dpdk-dev] [PATCH v1] ixgbe: remove vector pmd burst size restriction
> -Original Message- > From: Liang, Cunming > Sent: Friday, July 31, 2015 9:18 AM > To: dev at dpdk.org > Cc: Ananyev, Konstantin; Liang, Cunming > Subject: [PATCH v1] ixgbe: remove vector pmd burst size restriction > > The patch removes the restriction of burst size on a constant 32. > > On receive side, the burst size floor now aligns to RTE_IXGBE_DESCS_PER_LOOP > power of 2. > According to this rule, the burst size less than 4 still won't receive > anything. > (Before this change, the burst size less than 32 can't receive anything.) > > On transmit side, the max burst size no longer bind with a constant, however > it still > require to check the cross tx_rs_thresh violation. > > There's no obvious performance drop found on both recv_pkts_vec > and recv_scattered_pkts_vec on burst size 32. > > Signed-off-by: Cunming Liang > --- Acked-by: Konstantin Ananyev
[dpdk-dev] [PATCH v1] ixgbe: remove vector pmd burst size restriction
On 31/07/15 09:17, Cunming Liang wrote:
> The patch removes the restriction of burst size on a constant 32.
>
> On receive side, the burst size floor now aligns to RTE_IXGBE_DESCS_PER_LOOP
> power of 2.
> According to this rule, the burst size less than 4 still won't receive
> anything.
> (Before this change, the burst size less than 32 can't receive anything.)
>
> On transmit side, the max burst size no longer bind with a constant, however
> it still
> require to check the cross tx_rs_thresh violation.
>
> There's no obvious performance drop found on both recv_pkts_vec
> and recv_scattered_pkts_vec on burst size 32.
>
> Signed-off-by: Cunming Liang
> ---
> drivers/net/ixgbe/ixgbe_rxtx.c | 3 ++-
> drivers/net/ixgbe/ixgbe_rxtx.h | 4 +---
> drivers/net/ixgbe/ixgbe_rxtx_vec.c | 35 ---
> 3 files changed, 19 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/net/ixgbe/ixgbe_rxtx.c b/drivers/net/ixgbe/ixgbe_rxtx.c
> index 3f808b3..dbdb761 100644
> --- a/drivers/net/ixgbe/ixgbe_rxtx.c
> +++ b/drivers/net/ixgbe/ixgbe_rxtx.c
> @@ -4008,7 +4008,8 @@ ixgbe_set_rx_function(struct rte_eth_dev *dev)
>*/
> } else if (adapter->rx_vec_allowed) {
> PMD_INIT_LOG(DEBUG, "Vector rx enabled, please make sure RX "
> -"burst size no less than 32.");
> + "burst size no less than 4 (port=%d).",
> + dev->data->port_id);
I think it would be better to use RTE_IXGBE_DESCS_PER_LOOP instead of a
constant 4.
>
> dev->rx_pkt_burst = ixgbe_recv_pkts_vec;
> } else if (adapter->rx_bulk_alloc_allowed) {
> diff --git a/drivers/net/ixgbe/ixgbe_rxtx.h b/drivers/net/ixgbe/ixgbe_rxtx.h
> index 113682a..eb931fe 100644
> --- a/drivers/net/ixgbe/ixgbe_rxtx.h
> +++ b/drivers/net/ixgbe/ixgbe_rxtx.h
> @@ -47,9 +47,7 @@
> (uint64_t) ((mb)->buf_physaddr + RTE_PKTMBUF_HEADROOM)
>
> #ifdef RTE_IXGBE_INC_VECTOR
> -#define RTE_IXGBE_VPMD_RX_BURST 32
> -#define RTE_IXGBE_VPMD_TX_BURST 32
> -#define RTE_IXGBE_RXQ_REARM_THRESH RTE_IXGBE_VPMD_RX_BURST
> +#define RTE_IXGBE_RXQ_REARM_THRESH 32
> #define RTE_IXGBE_TX_MAX_FREE_BUF_SZ64
> #endif
>
> diff --git a/drivers/net/ixgbe/ixgbe_rxtx_vec.c
> b/drivers/net/ixgbe/ixgbe_rxtx_vec.c
> index 1c16dec..b72f817 100644
> --- a/drivers/net/ixgbe/ixgbe_rxtx_vec.c
> +++ b/drivers/net/ixgbe/ixgbe_rxtx_vec.c
> @@ -199,13 +199,11 @@ desc_to_olflags_v(__m128i descs[4], struct rte_mbuf
> **rx_pkts)
> #endif
>
> /*
> - * vPMD receive routine, now only accept (nb_pkts == RTE_IXGBE_VPMD_RX_BURST)
> - * in one loop
> + * vPMD raw receive routine
I would keep some warning there, like "(if nb_pkts <
RTE_IXGBE_DESCS_PER_LOOP, won't receive anything)"
>*
>* Notice:
> - * - nb_pkts < RTE_IXGBE_VPMD_RX_BURST, just return no packet
> - * - nb_pkts > RTE_IXGBE_VPMD_RX_BURST, only scan RTE_IXGBE_VPMD_RX_BURST
> - * numbers of DD bit
> + * - floor align nb_pkts to a RTE_IXGBE_DESC_PER_LOOP power-of-two
> + * - 'nb_pkts < 4' causes 0 packet receiving
Again, RTE_IXGBE_DESCS_PER_LOOP would be better than 4
>* - don't support ol_flags for rss and csum err
>*/
> static inline uint16_t
> @@ -240,8 +238,7 @@ _recv_raw_pkts_vec(struct ixgbe_rx_queue *rxq, struct
> rte_mbuf **rx_pkts,
> __m128i dd_check, eop_check;
> #endif /* RTE_NEXT_ABI */
>
> - if (unlikely(nb_pkts < RTE_IXGBE_VPMD_RX_BURST))
> - return 0;
> + nb_pkts = RTE_ALIGN_FLOOR(nb_pkts, RTE_IXGBE_DESCS_PER_LOOP);
>
> /* Just the act of getting into the function from the application is
>* going to cost about 7 cycles */
> @@ -310,7 +307,7 @@ _recv_raw_pkts_vec(struct ixgbe_rx_queue *rxq, struct
> rte_mbuf **rx_pkts,
>* D. fill info. from desc to mbuf
>*/
> #endif /* RTE_NEXT_ABI */
> - for (pos = 0, nb_pkts_recd = 0; pos < RTE_IXGBE_VPMD_RX_BURST;
> + for (pos = 0, nb_pkts_recd = 0; pos < nb_pkts;
> pos += RTE_IXGBE_DESCS_PER_LOOP,
> rxdp += RTE_IXGBE_DESCS_PER_LOOP) {
> __m128i descs[RTE_IXGBE_DESCS_PER_LOOP];
> @@ -450,13 +447,11 @@ _recv_raw_pkts_vec(struct ixgbe_rx_queue *rxq, struct
> rte_mbuf **rx_pkts,
> }
>
> /*
> - * vPMD receive routine, now only accept (nb_pkts == RTE_IXGBE_VPMD_RX_BURST)
> - * in one loop
> + * vPMD receive routine
Same note here as above
>*
>* Notice:
> - * - nb_pkts < RTE_IXGBE_VPMD_RX_BURST, just return no packet
> - * - nb_pkts > RTE_IXGBE_VPMD_RX_BURST, only scan RTE_IXGBE_VPMD_RX_BURST
> - * numbers of DD bit
> + * - floor align nb_pkts to a RTE_IXGBE_DESC_PER_LOOP power-of-two
> + * - 'nb_pkts < 4' causes 0 packet receiving
>* - don't support ol_flags for rss and csum err
>*/
> uint16_t
> @@ -470,12 +465,11 @@ static inline uint16_t
> reassemble_packets(struct ixgbe_rx_queue *rxq, struct rte_mbuf **rx_bufs,
> uint16_t nb_bu
[dpdk-dev] [PATCH v1] ixgbe: remove vector pmd burst size restriction
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Zoltan Kiss
> Sent: Friday, July 31, 2015 11:04 AM
> To: Liang, Cunming; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v1] ixgbe: remove vector pmd burst size
> restriction
>
>
>
> On 31/07/15 09:17, Cunming Liang wrote:
> > The patch removes the restriction of burst size on a constant 32.
> >
> > On receive side, the burst size floor now aligns to
> > RTE_IXGBE_DESCS_PER_LOOP power of 2.
> > According to this rule, the burst size less than 4 still won't receive
> > anything.
> > (Before this change, the burst size less than 32 can't receive anything.)
> >
> > On transmit side, the max burst size no longer bind with a constant,
> > however it still
> > require to check the cross tx_rs_thresh violation.
> >
> > There's no obvious performance drop found on both recv_pkts_vec
> > and recv_scattered_pkts_vec on burst size 32.
> >
> > Signed-off-by: Cunming Liang
> > ---
> > drivers/net/ixgbe/ixgbe_rxtx.c | 3 ++-
> > drivers/net/ixgbe/ixgbe_rxtx.h | 4 +---
> > drivers/net/ixgbe/ixgbe_rxtx_vec.c | 35
> > ---
> > 3 files changed, 19 insertions(+), 23 deletions(-)
> >
> > diff --git a/drivers/net/ixgbe/ixgbe_rxtx.c b/drivers/net/ixgbe/ixgbe_rxtx.c
> > index 3f808b3..dbdb761 100644
> > --- a/drivers/net/ixgbe/ixgbe_rxtx.c
> > +++ b/drivers/net/ixgbe/ixgbe_rxtx.c
> > @@ -4008,7 +4008,8 @@ ixgbe_set_rx_function(struct rte_eth_dev *dev)
> > */
> > } else if (adapter->rx_vec_allowed) {
> > PMD_INIT_LOG(DEBUG, "Vector rx enabled, please make sure RX "
> > - "burst size no less than 32.");
> > + "burst size no less than 4 (port=%d).",
> > +dev->data->port_id);
>
> I think it would be better to use RTE_IXGBE_DESCS_PER_LOOP instead of a
> constant 4.
> >
> > dev->rx_pkt_burst = ixgbe_recv_pkts_vec;
> > } else if (adapter->rx_bulk_alloc_allowed) {
> > diff --git a/drivers/net/ixgbe/ixgbe_rxtx.h b/drivers/net/ixgbe/ixgbe_rxtx.h
> > index 113682a..eb931fe 100644
> > --- a/drivers/net/ixgbe/ixgbe_rxtx.h
> > +++ b/drivers/net/ixgbe/ixgbe_rxtx.h
> > @@ -47,9 +47,7 @@
> > (uint64_t) ((mb)->buf_physaddr + RTE_PKTMBUF_HEADROOM)
> >
> > #ifdef RTE_IXGBE_INC_VECTOR
> > -#define RTE_IXGBE_VPMD_RX_BURST 32
> > -#define RTE_IXGBE_VPMD_TX_BURST 32
> > -#define RTE_IXGBE_RXQ_REARM_THRESH RTE_IXGBE_VPMD_RX_BURST
> > +#define RTE_IXGBE_RXQ_REARM_THRESH 32
> > #define RTE_IXGBE_TX_MAX_FREE_BUF_SZ64
> > #endif
> >
> > diff --git a/drivers/net/ixgbe/ixgbe_rxtx_vec.c
> > b/drivers/net/ixgbe/ixgbe_rxtx_vec.c
> > index 1c16dec..b72f817 100644
> > --- a/drivers/net/ixgbe/ixgbe_rxtx_vec.c
> > +++ b/drivers/net/ixgbe/ixgbe_rxtx_vec.c
> > @@ -199,13 +199,11 @@ desc_to_olflags_v(__m128i descs[4], struct rte_mbuf
> > **rx_pkts)
> > #endif
> >
> > /*
> > - * vPMD receive routine, now only accept (nb_pkts ==
> > RTE_IXGBE_VPMD_RX_BURST)
> > - * in one loop
> > + * vPMD raw receive routine
> I would keep some warning there, like "(if nb_pkts <
> RTE_IXGBE_DESCS_PER_LOOP, won't receive anything)"
>
> >*
> >* Notice:
> > - * - nb_pkts < RTE_IXGBE_VPMD_RX_BURST, just return no packet
> > - * - nb_pkts > RTE_IXGBE_VPMD_RX_BURST, only scan RTE_IXGBE_VPMD_RX_BURST
> > - * numbers of DD bit
> > + * - floor align nb_pkts to a RTE_IXGBE_DESC_PER_LOOP power-of-two
> > + * - 'nb_pkts < 4' causes 0 packet receiving
> Again, RTE_IXGBE_DESCS_PER_LOOP would be better than 4
>
> >* - don't support ol_flags for rss and csum err
> >*/
> > static inline uint16_t
> > @@ -240,8 +238,7 @@ _recv_raw_pkts_vec(struct ixgbe_rx_queue *rxq, struct
> > rte_mbuf **rx_pkts,
> > __m128i dd_check, eop_check;
> > #endif /* RTE_NEXT_ABI */
> >
> > - if (unlikely(nb_pkts < RTE_IXGBE_VPMD_RX_BURST))
> > - return 0;
> > + nb_pkts = RTE_ALIGN_FLOOR(nb_pkts, RTE_IXGBE_DESCS_PER_LOOP);
> >
> > /* Just the act of getting into the function from the application is
> > * going to cost about 7 cycles */
> > @@ -310,7 +307,7 @@ _recv_raw_pkts_vec(struct ixgbe_rx_queue *rxq, struct
> > rte_mbuf **rx_pkts,
> > * D. fill info. from desc to mbuf
> > */
> > #endif /* RTE_NEXT_ABI */
> > - for (pos = 0, nb_pkts_recd = 0; pos < RTE_IXGBE_VPMD_RX_BURST;
> > + for (pos = 0, nb_pkts_recd = 0; pos < nb_pkts;
> > pos += RTE_IXGBE_DESCS_PER_LOOP,
> > rxdp += RTE_IXGBE_DESCS_PER_LOOP) {
> > __m128i descs[RTE_IXGBE_DESCS_PER_LOOP];
> > @@ -450,13 +447,11 @@ _recv_raw_pkts_vec(struct ixgbe_rx_queue *rxq, struct
> > rte_mbuf **rx_pkts,
> > }
> >
> > /*
> > - * vPMD receive routine, now only accept (nb_pkts ==
> > RTE_IXGBE_VPMD_RX_BURST)
> > - * in one loop
> > + * vPMD receive routine
> Same note here as above
>
> >*
> >* Notice:
> > - * - nb_pkts < RTE_IXGBE_VPMD_RX_BUR
[dpdk-dev] [PATCH] ethdev: fix ABI breakage in lro code
On Fri, Jul 31, 2015 at 09:03:45AM +, Mcnamara, John wrote:
> > -Original Message-
> > From: Neil Horman [mailto:nhorman at tuxdriver.com]
> > Sent: Monday, July 13, 2015 3:00 PM
> > To: Mcnamara, John
> > Cc: dev at dpdk.org; vladz at cloudius-systems.com
> > Subject: Re: [dpdk-dev] [PATCH] ethdev: fix ABI breakage in lro code
> >
> > On Mon, Jul 13, 2015 at 10:47:03AM +, Mcnamara, John wrote:
> > > > -Original Message-
> > > > From: Neil Horman [mailto:nhorman at tuxdriver.com]
> > > > Sent: Monday, July 13, 2015 11:42 AM
> > > > To: Mcnamara, John
> > > > Cc: dev at dpdk.org; vladz at cloudius-systems.com
> > > > Subject: Re: [dpdk-dev] [PATCH] ethdev: fix ABI breakage in lro code
> > > >
> > > > On Mon, Jul 13, 2015 at 11:26:25AM +0100, John McNamara wrote:
> > > > > Fix for ABI breakage introduced in LRO addition. Moves lro
> > > > > bitfield to the end of the struct/member.
> > > > >
> > > > > Fixes: 8eecb3295aed (ixgbe: add LRO support)
> > > > >
> > > > > Signed-off-by: John McNamara
> > > > > ---
> > > > > lib/librte_ether/rte_ethdev.h | 4 ++--
> > > > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > > > >
> > > > > diff --git a/lib/librte_ether/rte_ethdev.h
> > > > > b/lib/librte_ether/rte_ethdev.h index 79bde89..1c3ace1 100644
> > > > > --- a/lib/librte_ether/rte_ethdev.h
> > > > > +++ b/lib/librte_ether/rte_ethdev.h
> > > > > @@ -1578,9 +1578,9 @@ struct rte_eth_dev_data {
> > > > > uint8_t port_id; /**< Device [external] port
> > identifier.
> > > > */
> > > > > uint8_t promiscuous : 1, /**< RX promiscuous mode ON(1) /
> > OFF(0).
> > > > */
> > > > > scattered_rx : 1, /**< RX of scattered packets is ON(1)
> > /
> > > > OFF(0) */
> > > > > - lro : 1, /**< RX LRO is ON(1) / OFF(0) */
> > > > > all_multicast : 1, /**< RX all multicast mode ON(1) /
> > OFF(0).
> > > > */
> > > > > - dev_started : 1; /**< Device state: STARTED(1) /
> > STOPPED(0).
> > > > */
> > > > > + dev_started : 1, /**< Device state: STARTED(1) /
> > STOPPED(0).
> > > > */
> > > > > + lro : 1; /**< RX LRO is ON(1) / OFF(0) */
> > > > > };
> > > > >
> > > > > /**
> > > > > --
> > > > > 1.8.1.4
> > > > >
> > > > >
> > > > I presume the ABI checker stopped complaining about this with the
> > > > patch, yes?
> > >
> > > Hi Neil,
> > >
> > > Yes, I replied about that in the previous thread.
> > >
> > Thank you, I'll ack as soon as Chao confirms its not a problem on ppc Neil
>
> Hi Chao,
>
> Any reply on this.
>
> Neil, if there is no reply to this from the PPC maintainer do you have any
> objection to this going in as is.
>
> It at least fixes the LRO ABI breakage on the platforms we can test on.
>
> John
>
Well, I suppose at this point the only thing its hurting is ppc, so no, no
objections. But its pretty disheartening for an arch maintainer to dissappear
so soon after adding arch support.
Neil
[dpdk-dev] [PATCH v2] i40e: fix for ieee15888 with rte_next_abi
Fixes issue where ieee15888 timestamping doesn't work for the i40e
pmd when RTE_ABI_NEXT is enabled.
Also refactors repeated ieee15888 flag checking and setting
code into a function.
Reported-by: Huilong Xu
Signed-off-by: John McNamara
---
v2: Fix for "unused function" warning with clang >= 3.4. Warning:
i40e_rxtx.c:183:1: error: unused function 'i40e_get_iee15888_flags'
[-Werror,-Wunused-function]
v1: Initial version
drivers/net/i40e/i40e_rxtx.c | 54
1 file changed, 29 insertions(+), 25 deletions(-)
diff --git a/drivers/net/i40e/i40e_rxtx.c b/drivers/net/i40e/i40e_rxtx.c
index 891a221..473fc0e 100644
--- a/drivers/net/i40e/i40e_rxtx.c
+++ b/drivers/net/i40e/i40e_rxtx.c
@@ -176,6 +176,32 @@ i40e_rxd_error_to_pkt_flags(uint64_t qword)
return flags;
}
+/* Function to check and set the ieee1588 timesync index and get the
+ * appropriate flags.
+ */
+#ifdef RTE_LIBRTE_IEEE1588
+static inline uint64_t
+i40e_get_iee15888_flags(struct rte_mbuf *mb, uint64_t qword)
+{
+ uint64_t pkt_flags = 0;
+ uint16_t tsyn = (qword & (I40E_RXD_QW1_STATUS_TSYNVALID_MASK
+ | I40E_RXD_QW1_STATUS_TSYNINDX_MASK))
+ >> I40E_RX_DESC_STATUS_TSYNINDX_SHIFT;
+
+#ifdef RTE_NEXT_ABI
+ if ((mb->packet_type & RTE_PTYPE_L2_MASK)
+ == RTE_PTYPE_L2_ETHER_TIMESYNC)
+ pkt_flags = PKT_RX_IEEE1588_PTP;
+#endif
+ if (tsyn & 0x04) {
+ pkt_flags |= PKT_RX_IEEE1588_TMST;
+ mb->timesync = tsyn & 0x03;
+ }
+
+ return pkt_flags;
+}
+#endif
+
#ifdef RTE_NEXT_ABI
/* For each value it means, datasheet of hardware can tell more details */
static inline uint32_t
@@ -1285,15 +1311,7 @@ i40e_rx_scan_hw_ring(struct i40e_rx_queue *rxq)
pkt_flags |= i40e_rxd_build_fdir(&rxdp[j], mb);
#ifdef RTE_LIBRTE_IEEE1588
- uint16_t tsyn = (qword1
-& (I40E_RXD_QW1_STATUS_TSYNVALID_MASK
- | I40E_RXD_QW1_STATUS_TSYNINDX_MASK))
->> I40E_RX_DESC_STATUS_TSYNINDX_SHIFT;
-
- if (tsyn & 0x04)
- pkt_flags |= PKT_RX_IEEE1588_TMST;
-
- mb->timesync = tsyn & 0x03;
+ pkt_flags |= i40e_get_iee15888_flags(mb, qword1);
#endif
mb->ol_flags |= pkt_flags;
@@ -1547,14 +1565,7 @@ i40e_recv_pkts(void *rx_queue, struct rte_mbuf
**rx_pkts, uint16_t nb_pkts)
pkt_flags |= i40e_rxd_build_fdir(&rxd, rxm);
#ifdef RTE_LIBRTE_IEEE1588
- uint16_t tsyn = (qword1 & (I40E_RXD_QW1_STATUS_TSYNVALID_MASK
- | I40E_RXD_QW1_STATUS_TSYNINDX_MASK))
- >> I40E_RX_DESC_STATUS_TSYNINDX_SHIFT;
-
- if (tsyn & 0x04)
- pkt_flags |= PKT_RX_IEEE1588_TMST;
-
- rxm->timesync = tsyn & 0x03;
+ pkt_flags |= i40e_get_iee15888_flags(rxm, qword1);
#endif
rxm->ol_flags |= pkt_flags;
@@ -1723,14 +1734,7 @@ i40e_recv_scattered_pkts(void *rx_queue,
pkt_flags |= i40e_rxd_build_fdir(&rxd, rxm);
#ifdef RTE_LIBRTE_IEEE1588
- uint16_t tsyn = (qword1 & (I40E_RXD_QW1_STATUS_TSYNVALID_MASK
- | I40E_RXD_QW1_STATUS_TSYNINDX_MASK))
- >> I40E_RX_DESC_STATUS_TSYNINDX_SHIFT;
-
- if (tsyn & 0x04)
- pkt_flags |= PKT_RX_IEEE1588_TMST;
-
- first_seg->timesync = tsyn & 0x03;
+ pkt_flags |= i40e_get_iee15888_flags(first_seg, qword1);
#endif
first_seg->ol_flags |= pkt_flags;
--
1.8.1.4
[dpdk-dev] [PATCH v1] ixgbe: remove vector pmd burst size restriction
On 31/07/15 11:21, Ananyev, Konstantin wrote:
>
>
>> -Original Message-
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Zoltan Kiss
>> Sent: Friday, July 31, 2015 11:04 AM
>> To: Liang, Cunming; dev at dpdk.org
>> Subject: Re: [dpdk-dev] [PATCH v1] ixgbe: remove vector pmd burst size
>> restriction
>>
>>
>>
>> On 31/07/15 09:17, Cunming Liang wrote:
>>> The patch removes the restriction of burst size on a constant 32.
>>>
>>> On receive side, the burst size floor now aligns to
>>> RTE_IXGBE_DESCS_PER_LOOP power of 2.
>>> According to this rule, the burst size less than 4 still won't receive
>>> anything.
>>> (Before this change, the burst size less than 32 can't receive anything.)
>>>
>>> On transmit side, the max burst size no longer bind with a constant,
>>> however it still
>>> require to check the cross tx_rs_thresh violation.
>>>
>>> There's no obvious performance drop found on both recv_pkts_vec
>>> and recv_scattered_pkts_vec on burst size 32.
>>>
>>> Signed-off-by: Cunming Liang
>>> ---
>>>drivers/net/ixgbe/ixgbe_rxtx.c | 3 ++-
>>>drivers/net/ixgbe/ixgbe_rxtx.h | 4 +---
>>>drivers/net/ixgbe/ixgbe_rxtx_vec.c | 35
>>> ---
>>>3 files changed, 19 insertions(+), 23 deletions(-)
>>>
>>> diff --git a/drivers/net/ixgbe/ixgbe_rxtx.c b/drivers/net/ixgbe/ixgbe_rxtx.c
>>> index 3f808b3..dbdb761 100644
>>> --- a/drivers/net/ixgbe/ixgbe_rxtx.c
>>> +++ b/drivers/net/ixgbe/ixgbe_rxtx.c
>>> @@ -4008,7 +4008,8 @@ ixgbe_set_rx_function(struct rte_eth_dev *dev)
>>> */
>>> } else if (adapter->rx_vec_allowed) {
>>> PMD_INIT_LOG(DEBUG, "Vector rx enabled, please make sure RX "
>>> - "burst size no less than 32.");
>>> + "burst size no less than 4 (port=%d).",
>>> +dev->data->port_id);
>>
>> I think it would be better to use RTE_IXGBE_DESCS_PER_LOOP instead of a
>> constant 4.
>>>
>>> dev->rx_pkt_burst = ixgbe_recv_pkts_vec;
>>> } else if (adapter->rx_bulk_alloc_allowed) {
>>> diff --git a/drivers/net/ixgbe/ixgbe_rxtx.h b/drivers/net/ixgbe/ixgbe_rxtx.h
>>> index 113682a..eb931fe 100644
>>> --- a/drivers/net/ixgbe/ixgbe_rxtx.h
>>> +++ b/drivers/net/ixgbe/ixgbe_rxtx.h
>>> @@ -47,9 +47,7 @@
>>> (uint64_t) ((mb)->buf_physaddr + RTE_PKTMBUF_HEADROOM)
>>>
>>>#ifdef RTE_IXGBE_INC_VECTOR
>>> -#define RTE_IXGBE_VPMD_RX_BURST 32
>>> -#define RTE_IXGBE_VPMD_TX_BURST 32
>>> -#define RTE_IXGBE_RXQ_REARM_THRESH RTE_IXGBE_VPMD_RX_BURST
>>> +#define RTE_IXGBE_RXQ_REARM_THRESH 32
>>>#define RTE_IXGBE_TX_MAX_FREE_BUF_SZ64
>>>#endif
>>>
>>> diff --git a/drivers/net/ixgbe/ixgbe_rxtx_vec.c
>>> b/drivers/net/ixgbe/ixgbe_rxtx_vec.c
>>> index 1c16dec..b72f817 100644
>>> --- a/drivers/net/ixgbe/ixgbe_rxtx_vec.c
>>> +++ b/drivers/net/ixgbe/ixgbe_rxtx_vec.c
>>> @@ -199,13 +199,11 @@ desc_to_olflags_v(__m128i descs[4], struct rte_mbuf
>>> **rx_pkts)
>>>#endif
>>>
>>>/*
>>> - * vPMD receive routine, now only accept (nb_pkts ==
>>> RTE_IXGBE_VPMD_RX_BURST)
>>> - * in one loop
>>> + * vPMD raw receive routine
>> I would keep some warning there, like "(if nb_pkts <
>> RTE_IXGBE_DESCS_PER_LOOP, won't receive anything)"
>>
>>> *
>>> * Notice:
>>> - * - nb_pkts < RTE_IXGBE_VPMD_RX_BURST, just return no packet
>>> - * - nb_pkts > RTE_IXGBE_VPMD_RX_BURST, only scan RTE_IXGBE_VPMD_RX_BURST
>>> - * numbers of DD bit
>>> + * - floor align nb_pkts to a RTE_IXGBE_DESC_PER_LOOP power-of-two
>>> + * - 'nb_pkts < 4' causes 0 packet receiving
>> Again, RTE_IXGBE_DESCS_PER_LOOP would be better than 4
>>
>>> * - don't support ol_flags for rss and csum err
>>> */
>>>static inline uint16_t
>>> @@ -240,8 +238,7 @@ _recv_raw_pkts_vec(struct ixgbe_rx_queue *rxq, struct
>>> rte_mbuf **rx_pkts,
>>> __m128i dd_check, eop_check;
>>>#endif /* RTE_NEXT_ABI */
>>>
>>> - if (unlikely(nb_pkts < RTE_IXGBE_VPMD_RX_BURST))
>>> - return 0;
>>> + nb_pkts = RTE_ALIGN_FLOOR(nb_pkts, RTE_IXGBE_DESCS_PER_LOOP);
>>>
>>> /* Just the act of getting into the function from the application is
>>> * going to cost about 7 cycles */
>>> @@ -310,7 +307,7 @@ _recv_raw_pkts_vec(struct ixgbe_rx_queue *rxq, struct
>>> rte_mbuf **rx_pkts,
>>> * D. fill info. from desc to mbuf
>>> */
>>>#endif /* RTE_NEXT_ABI */
>>> - for (pos = 0, nb_pkts_recd = 0; pos < RTE_IXGBE_VPMD_RX_BURST;
>>> + for (pos = 0, nb_pkts_recd = 0; pos < nb_pkts;
>>> pos += RTE_IXGBE_DESCS_PER_LOOP,
>>> rxdp += RTE_IXGBE_DESCS_PER_LOOP) {
>>> __m128i descs[RTE_IXGBE_DESCS_PER_LOOP];
>>> @@ -450,13 +447,11 @@ _recv_raw_pkts_vec(struct ixgbe_rx_queue *rxq, struct
>>> rte_mbuf **rx_pkts,
>>>}
>>>
>>>/*
>>> - * vPMD receive routine, now only accept (nb_pkts ==
>>> RTE_IXGBE_VPMD_RX_BURST)
>>> - * in one loop
>>> + * vPMD receive routine
>> Same note her
[dpdk-dev] [PATCH v2] i40e: fix for ieee15888 with rte_next_abi
On 31/07/2015 12:39, John McNamara wrote: > Fixes issue where ieee15888 timestamping doesn't work for the i40e > pmd when RTE_ABI_NEXT is enabled. > > Also refactors repeated ieee15888 flag checking and setting > code into a function. > > Reported-by: Huilong Xu > Signed-off-by: John McNamara > --- > > v2: Fix for "unused function" warning with clang >= 3.4. Warning: > > i40e_rxtx.c:183:1: error: unused function 'i40e_get_iee15888_flags' > [-Werror,-Wunused-function] > > v1: Initial version > > Acked-by: Sergio Gonzalez Monroy
[dpdk-dev] [PACTH v3 1/2] mk: use LDLIBS and EXTRA_LDFLAGS variable when building the shared object file
Some .so libraries needs to be linked with external libraries. For that the LDLIBS and EXTRA_LDFLAGS variables should be present on the link line when those .so files are created. PMD Makefile is responsible for filling the LDLIBS variable with the link to the external library it needs. Signed-off-by: Nelio Laranjeiro Acked-by: Olivier Matz --- Changelog: Update commit log. mk/rte.lib.mk | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/mk/rte.lib.mk b/mk/rte.lib.mk index 9ff5cce..fcc8e20 100644 --- a/mk/rte.lib.mk +++ b/mk/rte.lib.mk @@ -81,7 +81,8 @@ O_TO_A_DO = @set -e; \ $(O_TO_A) && \ echo $(O_TO_A_CMD) > $(call exe2cmd,$(@)) -O_TO_S = $(LD) $(_CPU_LDFLAGS) -shared $(OBJS-y) -Wl,-soname,$(LIB) -o $(LIB) +O_TO_S = $(LD) $(_CPU_LDFLAGS) $(EXTRA_LDFLAGS) $(LDLIBS) -shared $(OBJS-y) \ +-Wl,-soname,$(LIB) -o $(LIB) O_TO_S_STR = $(subst ','\'',$(O_TO_S)) #'# fix syntax highlight O_TO_S_DISP = $(if $(V),"$(O_TO_S_STR)"," LD $(@)") O_TO_S_DO = @set -e; \ -- 1.9.1
[dpdk-dev] [PACTH v3 2/2] mlx4: fix shared library dependency
librte_pmd_mlx4.so needs to be linked with libibverbs otherwise, the PMD is not able to open Mellanox devices and the following message is printed by testpmd at startup "librte_pmd_mlx4: cannot access device, is mlx4_ib loaded?". Applications dependency on libibverbs are moved to be only valid in static mode, in shared mode, applications do not depend on it anymore, librte_pmd_mlx4.so keeps this dependency and thus is linked with libibverbs. MLX4 cannot be supported in combined shared library because there is no clean way of adding -libverbs to the combined library. Signed-off-by: Nelio Laranjeiro Acked-by: Olivier Matz --- Changelog: fail the compilation of the PMD when the configuration is not supported. doc/guides/nics/mlx4.rst | 5 + drivers/net/mlx4/Makefile | 7 +++ mk/rte.app.mk | 3 +++ 3 files changed, 15 insertions(+) diff --git a/doc/guides/nics/mlx4.rst b/doc/guides/nics/mlx4.rst index c33aa38..562db06 100644 --- a/doc/guides/nics/mlx4.rst +++ b/doc/guides/nics/mlx4.rst @@ -47,6 +47,11 @@ There is also a `section dedicated to this poll mode driver be enabled manually by setting ``CONFIG_RTE_LIBRTE_MLX4_PMD=y`` and recompiling DPDK. +.. warning:: + + ``CONFIG_RTE_BUILD_COMBINE_LIBS`` with ``CONFIG_RTE_BUILD_SHARED_LIB`` + is not supported and thus the compilation will fail with this configuration. + Implementation details -- diff --git a/drivers/net/mlx4/Makefile b/drivers/net/mlx4/Makefile index 14cb53f..0399aff 100644 --- a/drivers/net/mlx4/Makefile +++ b/drivers/net/mlx4/Makefile @@ -31,6 +31,12 @@ include $(RTE_SDK)/mk/rte.vars.mk +ifeq ($(CONFIG_RTE_BUILD_COMBINE_LIBS)$(CONFIG_RTE_BUILD_SHARED_LIB),yy) +$(info MLX4: Not supported in a combined shared library) +all: + false +endif + # Library name. LIB = librte_pmd_mlx4.a @@ -50,6 +56,7 @@ CFLAGS += -g CFLAGS += -I. CFLAGS += -D_XOPEN_SOURCE=600 CFLAGS += $(WERROR_FLAGS) +LDLIBS += -libverbs # A few warnings cannot be avoided in external headers. CFLAGS += -Wno-error=cast-qual diff --git a/mk/rte.app.mk b/mk/rte.app.mk index 97719cb..3871205 100644 --- a/mk/rte.app.mk +++ b/mk/rte.app.mk @@ -100,7 +100,10 @@ ifeq ($(CONFIG_RTE_LIBRTE_VHOST_USER),n) _LDLIBS-$(CONFIG_RTE_LIBRTE_VHOST) += -lfuse endif +ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),n) _LDLIBS-$(CONFIG_RTE_LIBRTE_MLX4_PMD) += -libverbs +endif # ! CONFIG_RTE_BUILD_SHARED_LIBS + _LDLIBS-$(CONFIG_RTE_LIBRTE_BNX2X_PMD) += -lz _LDLIBS-y += --start-group -- 1.9.1
[dpdk-dev] [PATCH v1] ixgbe: remove vector pmd burst size restriction
On 31/07/15 12:57, Zoltan Kiss wrote: >> >> Another thing, that I just thought about: >> Right now we invoke ixgbe_rxq_rearm() only at the start of >> _recv_raw_pkts_vec(). >> Before it was ok, as _recv_raw_pkts_vec() would never try to read more >> then 32 RXDs. >> But what would happen if nb_pkts > rxq->nb_desc and rxq->rxrearm_nb == 0? > Yes, that call would deplete the RX ring, the card wouldn't be able to > receive more, so the receive function wouldn't be called again to rearm > the ring. > Actually not, the problem is that the recv function would probably overran the the descriptor ring. But anyway, we should limit nb_pkts indeed.
[dpdk-dev] config files maintenance
Hi, Currently most of the build options are duplicated in 2 config files. They should be merged in a common file to avoid this kind of differences: --- config/common_bsdapp +++ config/common_linuxapp -CONFIG_RTE_IXGBE_INC_VECTOR=n +CONFIG_RTE_IXGBE_INC_VECTOR=y -CONFIG_RTE_IXGBE_RX_OLFLAGS_DISABLE=n +CONFIG_RTE_IXGBE_RX_OLFLAGS_ENABLE=y -CONFIG_RTE_LIBRTE_I40E_RX_ALLOW_BULK_ALLOC=n +CONFIG_RTE_LIBRTE_I40E_RX_ALLOW_BULK_ALLOC=y Can we enable ixgbe SSE on BSD? CONFIG_RTE_IXGBE_RX_OLFLAGS_DISABLE must be renamed to CONFIG_RTE_IXGBE_RX_OLFLAGS_ENABLE, or can we remove this option? Can we remove i40e bulk alloc option? Why IEEE1588 is disabled? Can we remove this option? Please help to fix it for the release 2.1. After fixing the config, we have to think about simplifying it in 2.2. It would be easier to have some kind of config overlays: config_base config_bsd config_linux config_osv config_gcc config_icc config_clang config_i686 config_x86_64 config_x86_x32 config_ppc_64 config_tile-tilegx Then the defconfig files would include the above files. Or better, we could allow some paramaters to make config: make config ARCH= OS= CC= Thoughts?
[dpdk-dev] conflict between ether_addr defined in rte_ether.h and the same structure in
Hi all,
I 'm attempting to integrate DPDK code in an existing application, which
includes .
That standard glibc header already provides a structure named ether_addr
defined as:
struct ether_addr
{
u_int8_t ether_addr_octet[ETH_ALEN];
} __attribute__ ((__packed__));
So the result is that gcc complains about the redefinition:
dpdk/dpdk-2.0.0/x86_64-native-linuxapp-gcc/include/rte_ether.h:55:0: warning:
"ETHER_ADDR_LEN" redefined [enabled by default]
/opt/empirix/toolchains/x86_64-gcc-4.6.1-glibc-2.14-1.0-6/tools/include/net/ethernet.h:60:0:
note: this is the location of the previous definition
dpdk/dpdk-2.0.0/x86_64-native-linuxapp-gcc/include/rte_ether.h:58:0: warning:
"ETHER_HDR_LEN" redefined [enabled by default]
/opt/empirix/toolchains/x86_64-gcc-4.6.1-glibc-2.14-1.0-6/tools/include/net/ethernet.h:63:0:
note: this is the location of the previous definition
dpdk/dpdk-2.0.0/x86_64-native-linuxapp-gcc/include/rte_ether.h:60:0: warning:
"ETHER_MIN_LEN" redefined [enabled by default]
/opt/empirix/toolchains/x86_64-gcc-4.6.1-glibc-2.14-1.0-6/tools/include/net/ethernet.h:64:0:
note: this is the location of the previous definition
dpdk/dpdk-2.0.0/x86_64-native-linuxapp-gcc/include/rte_ether.h:61:0: warning:
"ETHER_MAX_LEN" redefined [enabled by default]
/opt/empirix/toolchains/x86_64-gcc-4.6.1-glibc-2.14-1.0-6/tools/include/net/ethernet.h:65:0:
note: this is the location of the previous definition
dpdk/dpdk-2.0.0/x86_64-native-linuxapp-gcc/include/rte_ether.h:86:8: error:
redefinition of 'struct ether_addr'
/opt/empirix/toolchains/x86_64-gcc-4.6.1-glibc-2.14-1.0-6/tools/include/net/ethernet.h:33:8:
error: previous definition of 'struct ether_addr'
dpdk/dpdk-2.0.0/x86_64-native-linuxapp-gcc/include/rte_ether.h: In function
'int is_same_ether_addr(const ether_addr*, const ether_addr*)':
dpdk/dpdk-2.0.0/x86_64-native-linuxapp-gcc/include/rte_ether.h:112:12: error:
'const struct ether_addr' has no member named 'addr_bytes'
dpdk/dpdk-2.0.0/x86_64-native-linuxapp-gcc/include/rte_ether.h:112:34: error:
'const struct ether_addr' has no member named 'addr_bytes'
dpdk/dpdk-2.0.0/x86_64-native-linuxapp-gcc/include/rte_ether.h: In function
'int is_zero_ether_addr(const ether_addr*)':
dpdk/dpdk-2.0.0/x86_64-native-linuxapp-gcc/include/rte_ether.h:131:11: error:
'const struct ether_addr' has no member named 'addr_bytes'
dpdk/dpdk-2.0.0/x86_64-native-linuxapp-gcc/include/rte_ether.h: In function
'int is_unicast_ether_addr(const ether_addr*)':
dpdk/dpdk-2.0.0/x86_64-native-linuxapp-gcc/include/rte_ether.h:148:15: error:
'const struct ether_addr' has no member named 'addr_bytes'
dpdk/dpdk-2.0.0/x86_64-native-linuxapp-gcc/include/rte_ether.h: In function
'int is_multicast_ether_addr(const ether_addr*)':
dpdk/dpdk-2.0.0/x86_64-native-linuxapp-gcc/include/rte_ether.h:163:14: error:
'const struct ether_addr' has no member named 'addr_bytes'
dpdk/dpdk-2.0.0/x86_64-native-linuxapp-gcc/include/rte_ether.h: In function
'int is_universal_ether_addr(const ether_addr*)':
dpdk/dpdk-2.0.0/x86_64-native-linuxapp-gcc/include/rte_ether.h:196:15: error:
'const struct ether_addr' has no member named 'addr_bytes'
dpdk/dpdk-2.0.0/x86_64-native-linuxapp-gcc/include/rte_ether.h: In function
'int is_local_admin_ether_addr(const ether_addr*)':
dpdk/dpdk-2.0.0/x86_64-native-linuxapp-gcc/include/rte_ether.h:211:15: error:
'const struct ether_addr' has no member named 'addr_bytes'
dpdk/dpdk-2.0.0/x86_64-native-linuxapp-gcc/include/rte_ether.h: In function
'void ether_format_addr(char*, uint16_t, const ether_addr*)':
dpdk/dpdk-2.0.0/x86_64-native-linuxapp-gcc/include/rte_ether.h:288:14: error:
'const struct ether_addr' has no member named 'addr_bytes'
dpdk/dpdk-2.0.0/x86_64-native-linuxapp-gcc/include/rte_ether.h:289:14: error:
'const struct ether_addr' has no member named 'addr_bytes'
dpdk/dpdk-2.0.0/x86_64-native-linuxapp-gcc/include/rte_ether.h:290:14: error:
'const struct ether_addr' has no member named 'addr_bytes'
dpdk/dpdk-2.0.0/x86_64-native-linuxapp-gcc/include/rte_ether.h:291:14: error:
'const struct ether_addr' has no member named 'addr_bytes'
dpdk/dpdk-2.0.0/x86_64-native-linuxapp-gcc/include/rte_ether.h:292:14: error:
'const struct ether_addr' has no member named 'addr_bytes'
dpdk/dpdk-2.0.0/x86_64-native-linuxapp-gcc/include/rte_ether.h:293:14: error:
'const struct ether_addr' has no member named 'addr_bytes'
My idea here is that DPDK should rather define an "rte_ether_addr" (or directly
always use but I guess this is not done for some good
reason)... isn't it?
Thanks,
Francesco Montorsi
[dpdk-dev] config files maintenance
> -Original Message- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Friday, July 31, 2015 8:08 AM > To: Zhang, Helin; Ananyev, Konstantin; Richardson, Bruce > Cc: dev at dpdk.org > Subject: config files maintenance > > Hi, > > Currently most of the build options are duplicated in 2 config files. > They should be merged in a common file to avoid this kind of differences: > > --- config/common_bsdapp > +++ config/common_linuxapp > -CONFIG_RTE_IXGBE_INC_VECTOR=n > +CONFIG_RTE_IXGBE_INC_VECTOR=y > -CONFIG_RTE_IXGBE_RX_OLFLAGS_DISABLE=n > +CONFIG_RTE_IXGBE_RX_OLFLAGS_ENABLE=y > -CONFIG_RTE_LIBRTE_I40E_RX_ALLOW_BULK_ALLOC=n > +CONFIG_RTE_LIBRTE_I40E_RX_ALLOW_BULK_ALLOC=y > > Can we enable ixgbe SSE on BSD? > CONFIG_RTE_IXGBE_RX_OLFLAGS_DISABLE must be renamed to > CONFIG_RTE_IXGBE_RX_OLFLAGS_ENABLE, or can we remove this option? > Can we remove i40e bulk alloc option? As the receiving functions are different for bulk_alloc or not, we need this flag. > Why IEEE1588 is disabled? Can we remove this option? I think the reason was it wanted to show the best performance by default, as more processing are needed for ieee1588 in fast path. I agree with you that we may need to re-think it. Thanks, Helin > > Please help to fix it for the release 2.1. > > After fixing the config, we have to think about simplifying it in 2.2. > It would be easier to have some kind of config overlays: > config_base > config_bsd > config_linux > config_osv > config_gcc > config_icc > config_clang > config_i686 > config_x86_64 > config_x86_x32 > config_ppc_64 > config_tile-tilegx > Then the defconfig files would include the above files. > Or better, we could allow some paramaters to make config: > make config ARCH= OS= CC= > > Thoughts?
[dpdk-dev] config files maintenance
2015-07-31 15:29, Zhang, Helin: > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > > Can we remove i40e bulk alloc option? > > As the receiving functions are different for bulk_alloc or not, we need this > flag. What brings the non bulk alloc function? Why is it disabled for BSD?
[dpdk-dev] Why only rx queue "0" can receive network packet by i40e NIC
> -Original Message-
> From: Jeff Venable, Sr. [mailto:jeff at vectranetworks.com]
> Sent: Wednesday, July 29, 2015 6:59 PM
> To: Zhang, Helin
> Cc: dev at dpdk.org; lhffjzh; 'Thomas Monjalon'
> Subject: RE: [dpdk-dev] Why only rx queue "0" can receive network packet by
> i40e NIC
>
> Hi Helin,
>
> We do not want RSS to include L4 ports in the hash because packet fragments
> would get routed to queue #0 and would be more difficult to work with. We are
> using the model where multiple CPUs are pulling from the NIC queues
> independently with no shared state, so each 'pipeline' has private fragment
> reassembly state for the sessions it is managing.
>
> Getting RSS Toeplitz hash to work on { source_ip, dest_ip } tuples only using
> a
> symmetric rss-key is important. This works properly with all other Intel
> NICs in
> the DPDK thus far that we have tested until the i40E PMD with the Intel
> X710-DA4.
> The Microsoft RSS specification allows for this.
This is a bit similar to some complains to flow director. I will check it with
somebody
else to see if there is anything we can do for this. And I remember there might
a bit hard.
Will let you know if I have any update.
Thanks,
Helin
>
> With the i40E PMD, we have been unsuccessful at enabling this RSS
> configuration.
> From the source code and XL710 controller datasheet, we cannot find any
> reference to the flags for this RSS mode. Unless we can achieve feature
> parity
> with the other Intel NICs, we don't want to write special case code for this
> one
> driver which makes the XL710 controller unusable for us and seems contrary to
> the intent of the DPDK APIs which are abstracting this behavior.
>
> Do you have any suggestions?
>
> Thanks kindly,
>
> Jeff
>
> -Original Message-
> From: Zhang, Helin [mailto:helin.zhang at intel.com]
> Sent: Wednesday, July 22, 2015 5:56 PM
> To: Jeff Venable, Sr. ; lhffjzh 126.com>;
> 'Thomas Monjalon'
> Cc: dev at dpdk.org
> Subject: RE: [dpdk-dev] Why only rx queue "0" can receive network packet by
> i40e NIC
>
>
>
> > -Original Message-
> > From: Jeff Venable, Sr. [mailto:jeff at vectranetworks.com]
> > Sent: Wednesday, July 22, 2015 5:47 PM
> > To: Zhang, Helin; lhffjzh; 'Thomas Monjalon'
> > Cc: dev at dpdk.org
> > Subject: RE: [dpdk-dev] Why only rx queue "0" can receive network
> > packet by i40e NIC
> >
> > Is the I40E incapable of operating RSS with ETH_RSS_IP (i.e. hashing
> > without L4 ports)?
> Why do you think like this? Sorry, I am a bit confused.
> ETH_RSS_IP is a super set of all IP based rss types. Please see the rss types
> listed
> in rte_ethdev.h.
> The supports rss types of each NIC can be queried via 'struct
> rte_eth_dev_info'
> of field 'flow_type_rss_offloads'.
>
> Regards,
> Helin
>
> >
> > Thanks,
> >
> > Jeff
> >
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Zhang, Helin
> > Sent: Saturday, February 28, 2015 6:34 AM
> > To: lhffjzh; 'Thomas Monjalon'
> > Cc: dev at dpdk.org; maintainers at dpdk.org
> > Subject: Re: [dpdk-dev] Why only rx queue "0" can receive network
> > packet by i40e NIC
> >
> > Good to know that!
> >
> > > -Original Message-
> > > From: lhffjzh [mailto:lhffjzh at 126.com]
> > > Sent: Saturday, February 28, 2015 12:34 PM
> > > To: Zhang, Helin; 'Thomas Monjalon'
> > > Cc: dev at dpdk.org; maintainers at dpdk.org
> > > Subject: RE: [dpdk-dev] Why only rx queue "0" can receive network
> > > packet by i40e NIC
> > >
> > > Hi Helin,
> > >
> > > Thanks a lot for your great help, all of rx queue received network
> > > packet after I update rss_hf from "ETH_RSS_IP" to " ETH_RSS_PROTO_MASK
> ".
> > >
> > > static struct rte_eth_conf port_conf = {
> > > .rxmode = {
> > > .mq_mode= ETH_MQ_RX_RSS,
> > > .max_rx_pkt_len = ETHER_MAX_LEN,
> > > .split_hdr_size = 0,
> > > .header_split = 0, /**< Header Split disabled */
> > > .hw_ip_checksum = 1, /**< IP checksum offload enabled */
> > > .hw_vlan_filter = 0, /**< VLAN filtering disabled */
> > > .jumbo_frame= 0, /**< Jumbo Frame Support disabled */
> > > .hw_strip_crc = 0, /**< CRC stripped by hardware */
> > > },
> > > .rx_adv_conf = {
> > > .rss_conf = {
> > > .rss_key = NULL,
> > > .rss_hf = ETH_RSS_PROTO_MASK,
> > > },
> > > },
> > > .txmode = {
> > > .mq_mode = ETH_MQ_TX_NONE,
> > > },
> > > .fdir_conf.mode = RTE_FDIR_MODE_SIGNATURE, };
> > >
> > >
> > > Regards,
> > > Haifeng
> > >
> > > -Original Message-
> > > From: Zhang, Helin [mailto:helin.zhang at intel.com]
> > > Sent: Saturday, February 28, 2015 11:18 AM
> > > To: lhffjzh; 'Thomas Monjalon'
> > > Cc: dev at dpdk.org; maintainers at dpdk.org
> > > Subject: RE: [dpdk-dev] Why only rx queue "0" can receive network
> > > packet by i40e NIC
> > >
> > > Hi Haifeng
> > >
> > > > -Original Message-
> > > > Fro
[dpdk-dev] conflict between ether_addr defined in rte_ether.h and the same structure in
Hi Francesco, 2015-07-31 15:18, Montorsi, Francesco: > I 'm attempting to integrate DPDK code in an existing application, > which includes . > That standard glibc header already provides a structure named ether_addr Yes it's a known problem. See http://dpdk.org/dev/patchwork/patch/2175/ Comments or help is welcome. CC'ing Stephen who worked on a patch.
[dpdk-dev] config files maintenance
> -Original Message- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Friday, July 31, 2015 8:31 AM > To: Zhang, Helin > Cc: Ananyev, Konstantin; Richardson, Bruce; dev at dpdk.org > Subject: Re: config files maintenance > > 2015-07-31 15:29, Zhang, Helin: > > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > > > Can we remove i40e bulk alloc option? > > > > As the receiving functions are different for bulk_alloc or not, we need > > this flag. > > What brings the non bulk alloc function? Bulk-alloc means it will allocate mbufs in bulk, which was added before we supporting Vector PMD long long ago, to show the possible better performance. I think all was disabled by default, and later it is enabled by default for Linux. > Why is it disabled for BSD? So now the question is can it be enabled for BSD by default, right? I guess yes, but others may give the accurate answer. Regards, Helin
[dpdk-dev] config files maintenance
Hi Thomas, > -Original Message- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Friday, July 31, 2015 4:08 PM > To: Zhang, Helin; Ananyev, Konstantin; Richardson, Bruce > Cc: dev at dpdk.org > Subject: config files maintenance > > Hi, > > Currently most of the build options are duplicated in 2 config files. > They should be merged in a common file to avoid this kind of differences: > > --- config/common_bsdapp > +++ config/common_linuxapp > -CONFIG_RTE_IXGBE_INC_VECTOR=n > +CONFIG_RTE_IXGBE_INC_VECTOR=y > -CONFIG_RTE_IXGBE_RX_OLFLAGS_DISABLE=n > +CONFIG_RTE_IXGBE_RX_OLFLAGS_ENABLE=y > -CONFIG_RTE_LIBRTE_I40E_RX_ALLOW_BULK_ALLOC=n > +CONFIG_RTE_LIBRTE_I40E_RX_ALLOW_BULK_ALLOC=y > > Can we enable ixgbe SSE on BSD? I think yes, though I never tried myself to run vecPMD on freebsd. > CONFIG_RTE_IXGBE_RX_OLFLAGS_DISABLE must be renamed to > CONFIG_RTE_IXGBE_RX_OLFLAGS_ENABLE, or can we remove this option? I think we can remove RTE_IXGBE_RX_OLFLAGS_ENABLE. Konstantin > Can we remove i40e bulk alloc option? > Why IEEE1588 is disabled? Can we remove this option? > > Please help to fix it for the release 2.1. > > After fixing the config, we have to think about simplifying it in 2.2. > It would be easier to have some kind of config overlays: > config_base > config_bsd > config_linux > config_osv > config_gcc > config_icc > config_clang > config_i686 > config_x86_64 > config_x86_x32 > config_ppc_64 > config_tile-tilegx > Then the defconfig files would include the above files. > Or better, we could allow some paramaters to make config: > make config ARCH= OS= CC= > > Thoughts?
[dpdk-dev] config files maintenance
2015-07-31 15:39, Zhang, Helin: > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > > 2015-07-31 15:29, Zhang, Helin: > > > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > > > > Can we remove i40e bulk alloc option? > > > > > > As the receiving functions are different for bulk_alloc or not, we need > > > this flag. > > > > What brings the non bulk alloc function? > > Bulk-alloc means it will allocate mbufs in bulk, which was added before we > supporting > Vector PMD long long ago, to show the possible better performance. > I think all was disabled by default, and later it is enabled by default for > Linux. Yes, I know that. My question was: Why not removing the non bulk alloc Rx in i40e? Who needs to disable I40E_RX_ALLOW_BULK_ALLOC? I think you understand that the goal is remove some options and code useless nowadays (maintenance stuff).
[dpdk-dev] config files maintenance
> -Original Message- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Friday, July 31, 2015 8:43 AM > To: Zhang, Helin > Cc: Ananyev, Konstantin; Richardson, Bruce; dev at dpdk.org > Subject: Re: config files maintenance > > 2015-07-31 15:39, Zhang, Helin: > > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > > > 2015-07-31 15:29, Zhang, Helin: > > > > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > > > > > Can we remove i40e bulk alloc option? > > > > > > > > As the receiving functions are different for bulk_alloc or not, we need > > > > this > flag. > > > > > > What brings the non bulk alloc function? > > > > Bulk-alloc means it will allocate mbufs in bulk, which was added > > before we supporting Vector PMD long long ago, to show the possible better > performance. > > I think all was disabled by default, and later it is enabled by default for > > Linux. > > Yes, I know that. My question was: > Why not removing the non bulk alloc Rx in i40e? > Who needs to disable I40E_RX_ALLOW_BULK_ALLOC? > > I think you understand that the goal is remove some options and code useless > nowadays (maintenance stuff). I remember that last time somebody else were discussing about removing that, but finally gave up. Let me find out why they gave up, and then see if we can remove it later. Thanks, Helin
[dpdk-dev] config files maintenance
2015-07-31 17:08, Thomas Monjalon: > Can we enable ixgbe SSE on BSD? > CONFIG_RTE_IXGBE_RX_OLFLAGS_DISABLE must be renamed to > CONFIG_RTE_IXGBE_RX_OLFLAGS_ENABLE, or can we remove this option? > Can we remove i40e bulk alloc option? > Why IEEE1588 is disabled? Can we remove this option? One more question: Can we remove CONFIG_RTE_PMD_PACKET_PREFETCH (always enabled)?
[dpdk-dev] [PATCH 0/3] sync linux/bsd config options
Fix config options for ixgbe, i40e and KNI for BSD. Thomas Monjalon (3): ixgbe: fix offload config option name config: enable same drivers options for linux and bsd config: remove kni options for bsd config/common_bsdapp | 17 +++-- doc/guides/nics/ixgbe.rst | 6 +++--- 2 files changed, 6 insertions(+), 17 deletions(-) -- 2.4.2
[dpdk-dev] [PATCH 1/3] ixgbe: fix offload config option name
The RX_OLFLAGS option was renamed from DISABLE to ENABLE in driver code
and linux config.
It is now renamed also in bsd config and documentation.
Fixes: 359f106a69a9 ("ixgbe: prefer enabling olflags rather than not disabling")
Signed-off-by: Thomas Monjalon
---
config/common_bsdapp | 2 +-
doc/guides/nics/ixgbe.rst | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/config/common_bsdapp b/config/common_bsdapp
index 2c6eb40..650de38 100644
--- a/config/common_bsdapp
+++ b/config/common_bsdapp
@@ -174,7 +174,7 @@ CONFIG_RTE_LIBRTE_IXGBE_DEBUG_TX_FREE=n
CONFIG_RTE_LIBRTE_IXGBE_DEBUG_DRIVER=n
CONFIG_RTE_LIBRTE_IXGBE_PF_DISABLE_STRIP_CRC=n
CONFIG_RTE_IXGBE_INC_VECTOR=n
-CONFIG_RTE_IXGBE_RX_OLFLAGS_DISABLE=n
+CONFIG_RTE_IXGBE_RX_OLFLAGS_ENABLE=y
#
# Compile burst-oriented I40E PMD driver
diff --git a/doc/guides/nics/ixgbe.rst b/doc/guides/nics/ixgbe.rst
index 62cc0aa..8cae299 100644
--- a/doc/guides/nics/ixgbe.rst
+++ b/doc/guides/nics/ixgbe.rst
@@ -95,7 +95,7 @@ Other features are supported using optional MACRO
configuration. They include:
* HW extend dual VLAN
-* Enabled by RX_OLFLAGS (RTE_IXGBE_RX_OLFLAGS_DISABLE=n)
+* Enabled by RX_OLFLAGS (RTE_IXGBE_RX_OLFLAGS_ENABLE=y)
To guarantee the constraint, configuration flags in dev_conf.rxmode will be
checked:
@@ -154,13 +154,13 @@ Sample Application Notes
testpmd
^^^
-By default, using CONFIG_RTE_IXGBE_RX_OLFLAGS_DISABLE=n:
+By default, using CONFIG_RTE_IXGBE_RX_OLFLAGS_ENABLE=y:
.. code-block:: console
./x86_64-native-linuxapp-gcc/app/testpmd -c 300 -n 4 -- -i --burst=32
--rxfreet=32 --mbcache=250 --txpt=32 --rxht=8 --rxwt=0 --txfreet=32 --txrst=32
--txqflags=0xf01
-When CONFIG_RTE_IXGBE_RX_OLFLAGS_DISABLE=y, better performance can be achieved:
+When CONFIG_RTE_IXGBE_RX_OLFLAGS_ENABLE=n, better performance can be achieved:
.. code-block:: console
--
2.4.2
[dpdk-dev] [PATCH 2/3] config: enable same drivers options for linux and bsd
Enable vector ixgbe and i40e bulk alloc for bsd as it is
already done for linux.
Fixes: 304caba12643 ("config: fix bsd options")
Fixes: 0ff3324da2eb ("ixgbe: rework vector pmd following mbuf changes")
Signed-off-by: Thomas Monjalon
---
config/common_bsdapp | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/config/common_bsdapp b/config/common_bsdapp
index 650de38..1e0c625 100644
--- a/config/common_bsdapp
+++ b/config/common_bsdapp
@@ -173,7 +173,7 @@ CONFIG_RTE_LIBRTE_IXGBE_DEBUG_TX=n
CONFIG_RTE_LIBRTE_IXGBE_DEBUG_TX_FREE=n
CONFIG_RTE_LIBRTE_IXGBE_DEBUG_DRIVER=n
CONFIG_RTE_LIBRTE_IXGBE_PF_DISABLE_STRIP_CRC=n
-CONFIG_RTE_IXGBE_INC_VECTOR=n
+CONFIG_RTE_IXGBE_INC_VECTOR=y
CONFIG_RTE_IXGBE_RX_OLFLAGS_ENABLE=y
#
@@ -185,7 +185,7 @@ CONFIG_RTE_LIBRTE_I40E_DEBUG_RX=n
CONFIG_RTE_LIBRTE_I40E_DEBUG_TX=n
CONFIG_RTE_LIBRTE_I40E_DEBUG_TX_FREE=n
CONFIG_RTE_LIBRTE_I40E_DEBUG_DRIVER=n
-CONFIG_RTE_LIBRTE_I40E_RX_ALLOW_BULK_ALLOC=n
+CONFIG_RTE_LIBRTE_I40E_RX_ALLOW_BULK_ALLOC=y
CONFIG_RTE_LIBRTE_I40E_16BYTE_RX_DESC=n
CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_VF=4
CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_VM=4
--
2.4.2
[dpdk-dev] [PATCH 3/3] config: remove kni options for bsd
KNI is a Linux-only kernel module. Signed-off-by: Thomas Monjalon --- config/common_bsdapp | 11 --- 1 file changed, 11 deletions(-) diff --git a/config/common_bsdapp b/config/common_bsdapp index 1e0c625..b37dcf4 100644 --- a/config/common_bsdapp +++ b/config/common_bsdapp @@ -414,17 +414,6 @@ CONFIG_RTE_LIBRTE_PIPELINE=y CONFIG_RTE_PIPELINE_STATS_COLLECT=n # -# Compile librte_kni -# -CONFIG_RTE_LIBRTE_KNI=n -CONFIG_RTE_KNI_KO_DEBUG=n -CONFIG_RTE_KNI_VHOST=n -CONFIG_RTE_KNI_VHOST_MAX_CACHE_SIZE=1024 -CONFIG_RTE_KNI_VHOST_VNET_HDR_EN=n -CONFIG_RTE_KNI_VHOST_DEBUG_RX=n -CONFIG_RTE_KNI_VHOST_DEBUG_TX=n - -# # Enable warning directives # CONFIG_RTE_INSECURE_FUNCTION_WARNING=n -- 2.4.2
[dpdk-dev] [PATCH 3/3] config: remove kni options for bsd
> -Original Message- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Friday, July 31, 2015 2:12 PM > To: Zhang, Helin; Ananyev, Konstantin; Richardson, Bruce > Cc: dev at dpdk.org > Subject: [PATCH 3/3] config: remove kni options for bsd > > KNI is a Linux-only kernel module. > > Signed-off-by: Thomas Monjalon Acked-by: Helin Zhang
