[dpdk-dev] [PATCH] net/mlx5: fix wrong use of vector instruction
Constraint alignment was not respected in Tx.
Fixes: 1d88ba171942 ("net/mlx5: refactor Tx data path")
Signed-off-by: Elad Persiko
---
drivers/net/mlx5/mlx5_rxtx.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/mlx5/mlx5_rxtx.c b/drivers/net/mlx5/mlx5_rxtx.c
index 21164ba..ba8e202 100644
--- a/drivers/net/mlx5/mlx5_rxtx.c
+++ b/drivers/net/mlx5/mlx5_rxtx.c
@@ -309,7 +309,7 @@ mlx5_tx_dbrec(struct txq *txq)
*txq->qp_db = htonl(txq->wqe_ci);
/* Ensure ordering between DB record and BF copy. */
rte_wmb();
- rte_mov16(dst, (uint8_t *)data);
+ memcpy(dst, (uint8_t *)data, 16);
txq->bf_offset ^= (1 << txq->bf_buf_size);
}
@@ -449,7 +449,7 @@ mlx5_tx_burst(void *dpdk_txq, struct rte_mbuf **pkts,
uint16_t pkts_n)
wqe->eseg.mss = 0;
wqe->eseg.rsvd2 = 0;
/* Start by copying the Ethernet Header. */
- rte_mov16((uint8_t *)raw, (uint8_t *)addr);
+ memcpy((uint8_t *)raw, ((uint8_t *)addr), 16);
length -= MLX5_WQE_DWORD_SIZE;
addr += MLX5_WQE_DWORD_SIZE;
/* Replace the Ethernet type by the VLAN if necessary. */
--
1.8.3.1
[dpdk-dev] [PATCH v4] vhost: Add indirect descriptors support to the TX path
On Fri, Oct 28, 2016 at 09:58:51AM +0200, Maxime Coquelin wrote: > >From my experience, and as Michael pointed out, the best mode for small > >packets is obviously > >ANY_LAYOUT so it uses a single descriptor per packet. > Of course, having a single descriptor is in theory the best way. > But, in current Virtio PMD implementation, with no offload supported, we > never access the virtio header at transmit time, it is allocated and > zeroed at startup. > > For ANY_LAYOUT case, the virtio header is prepended to the packet, and > need to be zeroed at packet transmit time. The performance impact is > quite important, as show the measurements I made one month ago (txonly): > - 2 descs per packet: 11.6Mpps > - 1 desc per packet: 9.6Mpps > > As Michael suggested, I tried to replace the memset by direct > fields assignation, but it only recovers a small part of the drop. > > What I suggested is to introduce a new feature, so that we can skip the > virtio header when no offload is negotiated. > > Maybe you have other ideas? > > >So, disabling indirect descriptors may give you better pps for 64 bytes > >packets, but that doesn't mean you should not implement, or enable, it in > >your driver. That just means that the guest is not taking the right > >decision, and uses indirect while it should actually use any_layout. > +1, it really depends on the use-case. > > > >Given virtio/vhost design (most decision comes from the guest), the host > >should be liberal in what it accepts, and not try to influence guest > >implementation by carefully picking the features it supports. Otherwise > >guests will never get a chance to make the right decisions either. > Agree, what we need is to be able to disable Virtio PMD features > without having to rebuild the PMD. I want this feature (or more precisely, ability) long times ago. For example, I'd wish there is an option like "force_legacy" when both legacy and modern exist. > It will certainly require an new API change to add this option. I don't think it will work. Firstly, generally, as discussed before, it's not a good idea to introduce some PMD specific APIs. Secondly, even if it's okay to do so, you need to let the application (say testpmd) invoke it. Once you have done that, you need introduce some CLI options to make sure that part is invoked. And as stated before, it's also not a good idea to add virtio PMD specific CLI options to testpmd. For this case, however, I think it makes more sense if test provides some commands to enable/disable csum and tso stuff. With that, we could enable it dynamically. It has "tso set/show" commands though: it just doesn't look like the right interface to me to enable/disable tso. --yliu
[dpdk-dev] [PATCH v4] vhost: Add indirect descriptors support to the TX path
2016-11-01 16:15, Yuanhan Liu: > On Fri, Oct 28, 2016 at 09:58:51AM +0200, Maxime Coquelin wrote: > > Agree, what we need is to be able to disable Virtio PMD features > > without having to rebuild the PMD. > > I want this feature (or more precisely, ability) long times ago. > For example, I'd wish there is an option like "force_legacy" when > both legacy and modern exist. You can change the behaviour of the driver with a run-time parameter as a struct rte_devargs.
[dpdk-dev] [PATCH v8] app/testpmd: fix DCB configuration
Data Centre Bridge (DCB) configuration fails when SRIOV is
enabled if nb_rxq and nb_txq are not set to 1.
The failure occurs during configuration of the ixgbe PMD when
it is started, in the ixgbe_check_mq_mode function.
Fixes: 2a977b891f99 ("app/testpmd: fix DCB configuration")
Signed-off-by: Bernard Iremonger
---
Changes in v8:
revise commit message.
Changes in v7:
restore nb_rxq and nb_txq setting when max_vfs is 0
app/test-pmd/testpmd.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index 6185be6..96f5011 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -2002,8 +2002,13 @@ init_port_dcb_config(portid_t pid,
* and has the same number of rxq and txq in dcb mode
*/
if (dcb_mode == DCB_VT_ENABLED) {
- nb_rxq = rte_port->dev_info.max_rx_queues;
- nb_txq = rte_port->dev_info.max_tx_queues;
+ if (rte_port->dev_info.max_vfs > 0) {
+ nb_rxq = 1;
+ nb_txq = 1;
+ } else {
+ nb_rxq = rte_port->dev_info.max_rx_queues;
+ nb_txq = rte_port->dev_info.max_tx_queues;
+ }
} else {
/*if vt is disabled, use all pf queues */
if (rte_port->dev_info.vmdq_pool_base == 0) {
--
2.4.3
[dpdk-dev] [PATCH] net/bonding: not handle vlan slow packet
Hi Haifeng,
On 10/31/2016 3:52 AM, linhaifeng wrote:
> From: Haifeng Lin
>
> if rx vlan offload is enable we should not handle vlan slow
> packets too.
>
> Signed-off-by: Haifeng Lin
> ---
> drivers/net/bonding/rte_eth_bond_pmd.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/bonding/rte_eth_bond_pmd.c
> b/drivers/net/bonding/rte_eth_bond_pmd.c
> index 09ce7bf..ca17898 100644
> --- a/drivers/net/bonding/rte_eth_bond_pmd.c
> +++ b/drivers/net/bonding/rte_eth_bond_pmd.c
> @@ -169,7 +169,8 @@ bond_ethdev_rx_burst_8023ad(void *queue, struct rte_mbuf
> **bufs,
> /* Remove packet from array if it is slow packet or
> slave is not
>* in collecting state or bondign interface is not in
> promiscus
>* mode and packet address does not match. */
> - if (unlikely(hdr->ether_type == ether_type_slow_be ||
> + if (unlikely((hdr->ether_type == ether_type_slow_be &&
> + !bufs[j]->vlan_tci) ||
> !collecting || (!promisc &&
> !is_multicast_ether_addr(&hdr->d_addr)
> &&
> !is_same_ether_addr(&bond_mac,
> &hdr->d_addr {
>
There are a few version of this patch, I guess this one is the correct
one, can you please confirm?
Also this one supersede following one, right?
http://dpdk.org/dev/patchwork/patch/16840/
It helps a lot if you use versioning in the patches [PATCH -vN] and add
a description of changes in commit log (after "---") between patch versions.
Thanks,
ferruh
[dpdk-dev] [PATCH] app/test: fix a segfault when lpm_perf_autotest is run more than 1 time
num_route_entries need to be reseted.
---
app/test/test_lpm_perf.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/app/test/test_lpm_perf.c b/app/test/test_lpm_perf.c
index 608e17a..e7e1281 100644
--- a/app/test/test_lpm_perf.c
+++ b/app/test/test_lpm_perf.c
@@ -301,6 +301,7 @@ static void generate_large_route_rule_table(void)
uint32_t ip_class;
uint8_t depth;
+ num_route_entries = 0;
memset(large_route_table, 0, sizeof(large_route_table));
for (ip_class = IP_CLASS_A; ip_class <= IP_CLASS_C; ip_class++) {
--
2.9.2
[dpdk-dev] [PATCH v2] app/test: fix a segfault when lpm_perf_autotest is run more than 1 time
num_route_entries need to be reseted.
V2 : resubmitting the patch with a signed-off
Signed-off-by: Nikita Kozlov
---
app/test/test_lpm_perf.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/app/test/test_lpm_perf.c b/app/test/test_lpm_perf.c
index 608e17a..e7e1281 100644
--- a/app/test/test_lpm_perf.c
+++ b/app/test/test_lpm_perf.c
@@ -301,6 +301,7 @@ static void generate_large_route_rule_table(void)
uint32_t ip_class;
uint8_t depth;
+ num_route_entries = 0;
memset(large_route_table, 0, sizeof(large_route_table));
for (ip_class = IP_CLASS_A; ip_class <= IP_CLASS_C; ip_class++) {
--
2.9.2
[dpdk-dev] [PATCH] app/test: fix a segfault when lpm_perf_autotest is run more than 1 time
On Tue, Nov 01, 2016 at 11:47:42AM +0100, Nikita Kozlov wrote: > num_route_entries need to be reseted. > --- > app/test/test_lpm_perf.c | 1 + > 1 file changed, 1 insertion(+) > You forgot your signoff on the patch, but I confirm it does indeed fix the issue. Also, as fixes line is needed to identify the commit that introduced the bug. Tested-by: Bruce Richardson
[dpdk-dev] [PATCH v3] app/test: fix a segfault when lpm_perf_autotest is run more than 1 time
num_route_entries need to be reseted.
Fixes: 17d60f5b5eea ("app/test: remove large IPv4 LPM data file")
Signed-off-by: Nikita Kozlov
---
app/test/test_lpm_perf.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/app/test/test_lpm_perf.c b/app/test/test_lpm_perf.c
index 608e17a..e7e1281 100644
--- a/app/test/test_lpm_perf.c
+++ b/app/test/test_lpm_perf.c
@@ -301,6 +301,7 @@ static void generate_large_route_rule_table(void)
uint32_t ip_class;
uint8_t depth;
+ num_route_entries = 0;
memset(large_route_table, 0, sizeof(large_route_table));
for (ip_class = IP_CLASS_A; ip_class <= IP_CLASS_C; ip_class++) {
--
2.9.2
[dpdk-dev] [PATCH] net/bonding: not handle vlan slow packet
? 2016/11/1 18:46, Ferruh Yigit ??:
> Hi Haifeng,
>
> On 10/31/2016 3:52 AM, linhaifeng wrote:
>> From: Haifeng Lin
>>
>> if rx vlan offload is enable we should not handle vlan slow
>> packets too.
>>
>> Signed-off-by: Haifeng Lin
>> ---
>> drivers/net/bonding/rte_eth_bond_pmd.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/bonding/rte_eth_bond_pmd.c
>> b/drivers/net/bonding/rte_eth_bond_pmd.c
>> index 09ce7bf..ca17898 100644
>> --- a/drivers/net/bonding/rte_eth_bond_pmd.c
>> +++ b/drivers/net/bonding/rte_eth_bond_pmd.c
>> @@ -169,7 +169,8 @@ bond_ethdev_rx_burst_8023ad(void *queue, struct rte_mbuf
>> **bufs,
>> /* Remove packet from array if it is slow packet or
>> slave is not
>> * in collecting state or bondign interface is not in
>> promiscus
>> * mode and packet address does not match. */
>> -if (unlikely(hdr->ether_type == ether_type_slow_be ||
>> +if (unlikely((hdr->ether_type == ether_type_slow_be &&
>> +!bufs[j]->vlan_tci) ||
>> !collecting || (!promisc &&
>> !is_multicast_ether_addr(&hdr->d_addr)
>> &&
>> !is_same_ether_addr(&bond_mac,
>> &hdr->d_addr {
>>
>
> There are a few version of this patch, I guess this one is the correct
> one, can you please confirm?
> Also this one supersede following one, right?
> http://dpdk.org/dev/patchwork/patch/16840/
yes?this is
>
> It helps a lot if you use versioning in the patches [PATCH -vN] and add
> a description of changes in commit log (after "---") between patch versions.
>
ok?i think should not send patch so worry??
I have a question to ask?
Is there any other packets' type also is 0x8809 except with lacp packets?
I saw some guests try to use this type to check link status between VM
but droped by lacp bond recv function.
> Thanks,
> ferruh
>
> .
>
[dpdk-dev] [PATCH v11 1/6] ethdev: add Tx preparation
Hi Thomas, > > > I suggest to integrate it in the beginning of 17.02 cycle, with the hope > > > that you can convince other developers to implement it in other drivers, > > > so we could finally enable it in the default config. > > > > Ok, any insights then, how we can convince people to do that? > > You just have to explain clearly what this new feature is bringing > and what will be the future possibilities. > > > BTW, it means then that tx_prep() should become part of mandatory API > > to be implemented by each PMD doing TX offloads, right? > > Right. > The question is "what means mandatory"? For me "mandatory" here would mean that: - if the PMD supports TX offloads AND - if to be able use any of these offloads the upper layer SW would have to: - modify the contents of the packet OR - obey HW specific restrictions then it is a PMD developer responsibility to provide tx_prep() that would implement expected modifications of the packet contents and restriction checks. Otherwise, tx_prep() implementation is not required and can be safely set to NULL. Does it sounds good enough to everyone? > Should we block some patches for non-compliant drivers? If we agree that it should be a 'mandatory' one - and patch in question breaks that requirement, then probably yes. > Should we remove offloads capability from non-compliant drivers? Do you mean existing PMDs? Are there any particular right now, that can't work properly with testpmd csumonly mode? Konstantin
[dpdk-dev] [PATCH] pmd_ring: fix coverity issue
Hi Mauricio,
On 11/1/2016 3:48 AM, Mauricio Vasquez B wrote:
> internals->data will never be NULL, so the check is not necessary.
>
> Fixes: d082c0395bf6 ("ring: fix memory leak when detaching")
> Coverity issue: 137873
>
> Signed-off-by: Mauricio Vasquez B
> ---
Thank you for the patch.
But "fix coverity issue" is not very descriptive title on its own.
Can you please describe what is really done in the patch, perhaps
something like:
"net/ring: remove unnecessary NULL check" ?
Thanks,
ferruh
[dpdk-dev] [PATCH] net/mlx5: fix wrong use of vector instruction
On 11/1/2016 8:13 AM, Elad Persiko wrote:
> Constraint alignment was not respected in Tx.
>
> Fixes: 1d88ba171942 ("net/mlx5: refactor Tx data path")
>
> Signed-off-by: Elad Persiko
> ---
> drivers/net/mlx5/mlx5_rxtx.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/mlx5/mlx5_rxtx.c b/drivers/net/mlx5/mlx5_rxtx.c
> index 21164ba..ba8e202 100644
> --- a/drivers/net/mlx5/mlx5_rxtx.c
> +++ b/drivers/net/mlx5/mlx5_rxtx.c
> @@ -309,7 +309,7 @@ mlx5_tx_dbrec(struct txq *txq)
> *txq->qp_db = htonl(txq->wqe_ci);
> /* Ensure ordering between DB record and BF copy. */
> rte_wmb();
> - rte_mov16(dst, (uint8_t *)data);
> + memcpy(dst, (uint8_t *)data, 16);
> txq->bf_offset ^= (1 << txq->bf_buf_size);
> }
>
> @@ -449,7 +449,7 @@ mlx5_tx_burst(void *dpdk_txq, struct rte_mbuf **pkts,
> uint16_t pkts_n)
> wqe->eseg.mss = 0;
> wqe->eseg.rsvd2 = 0;
> /* Start by copying the Ethernet Header. */
> - rte_mov16((uint8_t *)raw, (uint8_t *)addr);
> + memcpy((uint8_t *)raw, ((uint8_t *)addr), 16);
> length -= MLX5_WQE_DWORD_SIZE;
> addr += MLX5_WQE_DWORD_SIZE;
> /* Replace the Ethernet type by the VLAN if necessary. */
>
CC: Maintainers (Adrien Mazarguil )
[dpdk-dev] [PATCH] doc: add missing library to release notes
Signed-off-by: Ferruh Yigit --- CC: Olivier Matz --- doc/guides/rel_notes/release_16_11.rst | 1 + 1 file changed, 1 insertion(+) diff --git a/doc/guides/rel_notes/release_16_11.rst b/doc/guides/rel_notes/release_16_11.rst index aa0c09a..5f185be 100644 --- a/doc/guides/rel_notes/release_16_11.rst +++ b/doc/guides/rel_notes/release_16_11.rst @@ -248,6 +248,7 @@ The libraries prepended with a plus sign were incremented in this version. librte_mbuf.so.2 librte_mempool.so.2 librte_meter.so.1 + librte_net.so.1 librte_pdump.so.1 librte_pipeline.so.3 librte_pmd_bond.so.1 -- 2.7.4
[dpdk-dev] [PATCH] net: remove mempool as a dependency
Signed-off-by: Ferruh Yigit --- lib/librte_net/Makefile | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/lib/librte_net/Makefile b/lib/librte_net/Makefile index e5758ce..20cf664 100644 --- a/lib/librte_net/Makefile +++ b/lib/librte_net/Makefile @@ -45,7 +45,6 @@ SYMLINK-$(CONFIG_RTE_LIBRTE_NET)-include := rte_ip.h rte_tcp.h rte_udp.h SYMLINK-$(CONFIG_RTE_LIBRTE_NET)-include += rte_sctp.h rte_icmp.h rte_arp.h SYMLINK-$(CONFIG_RTE_LIBRTE_NET)-include += rte_ether.h rte_gre.h rte_net.h -DEPDIRS-$(CONFIG_RTE_LIBRTE_NET) += lib/librte_eal lib/librte_mempool -DEPDIRS-$(CONFIG_RTE_LIBRTE_NET) += lib/librte_mbuf +DEPDIRS-$(CONFIG_RTE_LIBRTE_NET) += lib/librte_eal lib/librte_mbuf include $(RTE_SDK)/mk/rte.lib.mk -- 2.7.4
[dpdk-dev] [PATCH] net/enic: fix max packet length check
When the device was configured with an explicit maximum packet length,
it would fail if the value was greater than MTU configured in CIMC/UCSM
(plus L2 header length). It should have been compared against maximum
allowed by the device.
Fixes: bb34ffb848a0 ("net/enic: determine max egress packet size and max MTU")
Signed-off-by: John Daley
---
drivers/net/enic/enic_ethdev.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/enic/enic_ethdev.c b/drivers/net/enic/enic_ethdev.c
index bcf83d4..2b154ec 100644
--- a/drivers/net/enic/enic_ethdev.c
+++ b/drivers/net/enic/enic_ethdev.c
@@ -463,8 +463,7 @@ static void enicpmd_dev_info_get(struct rte_eth_dev
*eth_dev,
device_info->max_rx_queues = enic->conf_rq_count / 2;
device_info->max_tx_queues = enic->conf_wq_count;
device_info->min_rx_bufsize = ENIC_MIN_MTU;
- device_info->max_rx_pktlen = enic->rte_dev->data->mtu
- + ETHER_HDR_LEN + 4;
+ device_info->max_rx_pktlen = enic->max_mtu + ETHER_HDR_LEN + 4;
device_info->max_mac_addrs = 1;
device_info->rx_offload_capa =
DEV_RX_OFFLOAD_VLAN_STRIP |
--
2.10.0
[dpdk-dev] [PATCH v2] net/ring: remove unnecessary NULL check
Coverity detected this as an issue because internals->data will never be NULL,
then the check is not necessary.
Fixes: d082c0395bf6 ("ring: fix memory leak when detaching")
Coverity issue: 137873
Signed-off-by: Mauricio Vasquez B
---
drivers/net/ring/rte_eth_ring.c | 20 +---
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ring/rte_eth_ring.c b/drivers/net/ring/rte_eth_ring.c
index 6d2a8c1..5ca00ed 100644
--- a/drivers/net/ring/rte_eth_ring.c
+++ b/drivers/net/ring/rte_eth_ring.c
@@ -599,17 +599,15 @@ rte_pmd_ring_remove(const char *name)
eth_dev_stop(eth_dev);
- if (eth_dev->data) {
- internals = eth_dev->data->dev_private;
- if (internals->action == DEV_CREATE) {
- /*
-* it is only necessary to delete the rings in
rx_queues because
-* they are the same used in tx_queues
-*/
- for (i = 0; i < eth_dev->data->nb_rx_queues; i++) {
- r = eth_dev->data->rx_queues[i];
- rte_ring_free(r->rng);
- }
+ internals = eth_dev->data->dev_private;
+ if (internals->action == DEV_CREATE) {
+ /*
+* it is only necessary to delete the rings in rx_queues because
+* they are the same used in tx_queues
+*/
+ for (i = 0; i < eth_dev->data->nb_rx_queues; i++) {
+ r = eth_dev->data->rx_queues[i];
+ rte_ring_free(r->rng);
}
rte_free(eth_dev->data->rx_queues);
--
1.9.1
[dpdk-dev] [PATCH] E1000: fix for forced speed/duplex config
>From the code, it looks like, hw->mac.autoneg, variable is used to
switch between calling either autoneg function or forcing
speed/duplex function. But this variable is not modified in
eth_em_start/eth_igb_start routines (it is always set to 1)
even while forcing the link speed.
Following discussion thread has some more information on
this
http://dpdk.org/ml/archives/dev/2016-October/049272.html
Signed-off-by: Ananda Sathyanarayana
---
drivers/net/e1000/em_ethdev.c | 16 ++--
drivers/net/e1000/igb_ethdev.c | 16 ++--
2 files changed, 28 insertions(+), 4 deletions(-)
diff --git a/drivers/net/e1000/em_ethdev.c b/drivers/net/e1000/em_ethdev.c
index 7cf5f0c..a2412f5 100644
--- a/drivers/net/e1000/em_ethdev.c
+++ b/drivers/net/e1000/em_ethdev.c
@@ -639,6 +639,7 @@ eth_em_start(struct rte_eth_dev *dev)
speeds = &dev->data->dev_conf.link_speeds;
if (*speeds == ETH_LINK_SPEED_AUTONEG) {
hw->phy.autoneg_advertised = E1000_ALL_SPEED_DUPLEX;
+hw->mac.autoneg = 1;
} else {
num_speeds = 0;
autoneg = (*speeds & ETH_LINK_SPEED_FIXED) == 0;
@@ -672,9 +673,20 @@ eth_em_start(struct rte_eth_dev *dev)
hw->phy.autoneg_advertised |= ADVERTISE_1000_FULL;
num_speeds++;
}
- if (num_speeds == 0 || (!autoneg && (num_speeds > 1)))
+ if (num_speeds == 0 || (!autoneg && (num_speeds > 1))) {
goto error_invalid_config;
- }
+}
+/*
+ * Set/reset the mac.autoneg based on the link speed,
+ * fixed or not
+ */
+if (!autoneg) {
+hw->mac.autoneg = 0;
+hw->mac.forced_speed_duplex =
hw->phy.autoneg_advertised;
+} else {
+hw->mac.autoneg = 1;
+}
+}
e1000_setup_link(hw);
diff --git a/drivers/net/e1000/igb_ethdev.c b/drivers/net/e1000/igb_ethdev.c
index 4924396..9fb498f 100644
--- a/drivers/net/e1000/igb_ethdev.c
+++ b/drivers/net/e1000/igb_ethdev.c
@@ -1327,6 +1327,7 @@ eth_igb_start(struct rte_eth_dev *dev)
speeds = &dev->data->dev_conf.link_speeds;
if (*speeds == ETH_LINK_SPEED_AUTONEG) {
hw->phy.autoneg_advertised = E1000_ALL_SPEED_DUPLEX;
+hw->mac.autoneg = 1;
} else {
num_speeds = 0;
autoneg = (*speeds & ETH_LINK_SPEED_FIXED) == 0;
@@ -1360,9 +1361,20 @@ eth_igb_start(struct rte_eth_dev *dev)
hw->phy.autoneg_advertised |= ADVERTISE_1000_FULL;
num_speeds++;
}
- if (num_speeds == 0 || (!autoneg && (num_speeds > 1)))
+ if (num_speeds == 0 || (!autoneg && (num_speeds > 1))) {
goto error_invalid_config;
- }
+}
+/*
+ * Set/reset the mac.autoneg based on the link speed,
+ * fixed or not
+ */
+if (!autoneg) {
+hw->mac.autoneg = 0;
+hw->mac.forced_speed_duplex =
hw->phy.autoneg_advertised;
+} else {
+hw->mac.autoneg = 1;
+}
+}
e1000_setup_link(hw);
--
1.9.1
[dpdk-dev] [PATCH] bnxt: use unsigned short instead of signed integer in bnxt_alloc_vnic_attributes
Prevent the arithmetic in bnxt_alloc_vnic_attributes from causing
any unintentional havoc because of the usage of a signed variable.
Coverity: 137874
Signed-off-by: Ajit Khaparde
---
drivers/net/bnxt/bnxt_vnic.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/bnxt/bnxt_vnic.c b/drivers/net/bnxt/bnxt_vnic.c
index 205a940..4cdca35 100644
--- a/drivers/net/bnxt/bnxt_vnic.c
+++ b/drivers/net/bnxt/bnxt_vnic.c
@@ -179,7 +179,7 @@ int bnxt_alloc_vnic_attributes(struct bnxt *bp)
HW_HASH_INDEX_SIZE * sizeof(*vnic->rss_table) +
HW_HASH_KEY_SIZE);
uint16_t max_vnics;
- int i;
+ uint16_t i;
if (BNXT_PF(bp)) {
struct bnxt_pf_info *pf = &bp->pf;
--
1.8.3.1
[dpdk-dev] [RFC PATCH v2 2/3] lib: add bitrate statistics library
On 28/10/2016 15:39, Morten Br?rup wrote: > Comments below. [..] > When working with statistical calculations using integer arithmetic, > you should round off the integer result by adding 0.5 to the result, > which you do by adding half of the divisor to the dividend, like > this: > > delta = (delta * alpha_percent + 50) / 100; > > The numbers in this particular case are probably very big, so not > rounding off doesn't affect the result a lot; but then you should add > a comment about why rounding down is acceptable. A minor point, but will roll it into the next patchset.
