We don't need to depend on rte_eth_dev->pci_dev to differentiate between
the virtio_user and the virtio_pci case. Instead we can use the private
virtio_hw struct to get that information.
Signed-off-by: Jan Blunck <jblunck@infradead.org>
Acked-by: Shreyansh Jain <shreyansh.jain@nxp.com>
This adds a helper to get the rte_intr_handle from the virtio_hw. This is
safe to do since the usage of the helper is guarded by RTE_ETH_DEV_INTR_LSC
which is only set if we found a PCI device during initialization.
Signed-off-by: Jan Blunck <jblunck@infradead.org>
Acked-by: Shreyansh Jain <shreyansh.jain@nxp.com>
This is overwritten in rte_eth_dev_info_get().
Signed-off-by: Jan Blunck <jblunck@infradead.org>
Reviewed-by: David Marchand <david.marchand@6wind.com>
Use existing information about pci and interrupt handle to minimize
the number of places that assume eth_dev contains pci_device
information.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Acked-by: Jan Blunck <jblunck@infradead.org>
Since later changes will change where PCI information is,
localize mapping in one macro.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Acked-by: Jan Blunck <jblunck@infradead.org>
Create one macro for where PCI device information is extracted
from ethernet device. Makes later changes easier to review, and test.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Acked-by: Jan Blunck <jblunck@infradead.org>
Since rte_eth_dev_info_get does memset() on dev_info before
calling device specific code, the explicit assignment of NULL
in all these virtual drivers has no effect.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Acked-by: Jan Blunck <jblunck@infradead.org>
This reverts commit 5b7bb2bda5.
It is necessary to reconfigure all queues every time because configuration
can be changed.
For example, if we're reconfiguring bonding device with new memory pool,
already configured queues will still use the old one. And if the old
mempool be freed, application likely will panic in attempt to use
freed mempool.
This happens when we use the bonding device with OVS 2.6 while MTU
reconfiguration:
PANIC in rte_mempool_get_ops():
assert "(ops_index >= 0) && (ops_index < RTE_MEMPOOL_MAX_OPS_IDX)" failed
Signed-off-by: Ilya Maximets <i.maximets@samsung.com>
Acked-by: Declan Doherty <declan.doherty@intel.com>
Acked-by: Jan Blunck <jblunck@infradead.org>
After a slave interface is removed from a bond group it still has the
configuration of the bond interface. Lets enforce that the slave interface
is reconfigured after removal by resetting it.
Signed-off-by: Jan Blunck <jblunck@infradead.org>
This moves the non-PCI related initialization of the link state interrupt
callback list and the setting of the default MTU to rte_eth_dev_allocate()
so that drivers only need to set non-default values.
Signed-off-by: Jan Blunck <jblunck@infradead.org>
Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
Lets clear the eth_dev->data when allocating a new rte_eth_dev so that
drivers only need to set non-zero values.
Signed-off-by: Jan Blunck <jblunck@infradead.org>
Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
Add a new macro RTE_PMD_REGISTER_KMOD_DEP() that allows a driver to
declare the list of kernel modules required to run properly.
Today, most PCI drivers require uio/vfio.
Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
Acked-by: Fiona Trahe <fiona.trahe@intel.com>
Acked-by: Adrien Mazarguil <adrien.mazarguil@6wind.com>
Today, all logs whose level is lower than INFO are dropped at
compile-time. This prevents from enabling debug logs at runtime using
--log-level=8.
The rationale was to remove debug logs from the data path at
compile-time, avoiding a test at run-time.
This patch changes the behavior of RTE_LOG() to avoid the compile-time
optimization, and introduces the RTE_LOG_DP() macro that has the same
behavior than the previous RTE_LOG(), for the rare cases where debug
logs are in the data path.
So it is now possible to enable debug logs at run-time by just
specifying --log-level=8. Some drivers still have special compile-time
options to enable more debug log. Maintainers may consider to
remove/reduce them.
Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
- Fix to use bitmapped values in NVM configuration for speed capability
advertisement. This issue is specific to 25G NIC since it is capable
of 25G and 10G speeds.
- Update feature list.
Fixes: 64c239b7f8 ("net/qede: fix advertising link speed capability")
Signed-off-by: Harish Patil <harish.patil@qlogic.com>
The links never coming up when bring up x552 NIC, device id is 15ac.
This is caused by delete some code which casing
removes X550em SFP iXFI setup for the drivers in function
ixgbe_setup_mac_link_sfp_x550em().
Fix method is recover the deleted code.
Fixes: 1726b9cd9c ("net/ixgbe/base: remove X550em SFP iXFI setup")
Signed-off-by: Wei Zhao <wei.zhao1@intel.com>
Acked-by: Wenzhuo Lu <wenzhuo.lu@intel.com>
83xx NIC subsystem differs in new PCI subsystem_device_id and
NICVF_CAP_DISABLE_APAD capability.
Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
Based on the packet type(IPv4 or IPv6), the nicvf HW aligns
L3 data to the 64bit memory address.
The alignment creates a hole in mbuf(between the
end of headroom and packet data start).
The new revision of the HW provides an option to disable
the L3 alignment feature and make mbuf layout looks
more like other NICs. For better application compatibility,
disabling l3 alignment feature on the hardware revisions it supports.
Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
We should not drop the slow packets which subtype is
not marker or lacp. Because slow packets have other subtype
like OAM,OSSP,user defined and so on.
Signed-off-by: Haifeng Lin <haifeng.lin@huawei.com>
Reviewed-by: Tomasz Kulasek <tomaszx.kulasek@intel.com>
During device reset/stop, vmxnet3 releases all mbufs in tx and
rx cmd ring. For rx, we should go over all ring descriptors and
free using rte_pktmbuf_free_seg() instead of rte_pktmbuf_free()
as the metadata of the mbuf might not be properly initialized
(initialization after mempool creation is done in the rx routine)
and the mbuf should always be a single-segment one when populated.
For tx, we can use the existing way as mbuf, if any, will be a
valid one stashed in the eop.
Fixes: dfaff37fc4 ("vmxnet3: import new vmxnet3 poll mode driver implementation")
Signed-off-by: Yong Wang <yongwang@vmware.com>
Using GCC_VERSION to check gcc version and decide whether to include
that compiler option.
Fixes: ecc7a5a27f ("net/qede/base: fix 32-bit build")
Signed-off-by: Rasesh Mody <rasesh.mody@cavium.com>
Fix to advertise device's link speed capability based on NVM
port configuration instead of returning driver supported speeds.
Fixes: 95e67b4795 ("net/qede: add 100G link speed capability")
Signed-off-by: Harish Patil <harish.patil@qlogic.com>
Some of the production parts will arrive after the 16.11 release.
Back off support for those devices. We will add these IDs again
at an appropriate time.
Signed-off-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
Prevent the arithmetic in bnxt_alloc_vnic_attributes from causing
any unintentional havoc because of the usage of a signed variable.
Coverity issue: 137874
Signed-off-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
This commit redefines the completion queue element structure as the
original lacks the required fields.
Signed-off-by: Nelio Laranjeiro <nelio.laranjeiro@6wind.com>
Acked-by: Adrien Mazarguil <adrien.mazarguil@6wind.com>
When mbufs are smaller than MRU, multi-segment support must be enabled to
default set when not in promiscuous or allmulticast modes.
Fixes: 9964b965ad ("net/mlx5: re-add Rx scatter support")
Signed-off-by: Raslan Darawsheh <rasland@mellanox.com>
Acked-by: Adrien Mazarguil <adrien.mazarguil@6wind.com>
Constraint alignment was not respected in Tx because of a
wrong use of vector instruction.
Fixes: 1d88ba1719 ("net/mlx5: refactor Tx data path")
Signed-off-by: Elad Persiko <eladpe@mellanox.com>
Acked-by: Adrien Mazarguil <adrien.mazarguil@6wind.com>
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: bb34ffb848 ("net/enic: determine max egress packet size and max MTU")
Signed-off-by: John Daley <johndale@cisco.com>
The next_to_clean and next_to_use ring pointers sometimes were kept
wrapped around ring size, sometimes used beyond this limit. From now
on we increment them without regard to ring size limits, but when
reading the values they are wrapped accordingly. Moreover unit16_t
are unsed whenever possible.
Signed-off-by: Tal Avraham <talavr@annapurnalabs.com>
Signed-off-by: Jakub Palider <jpa@semihalf.com>
If VF device is used as slave of a bond device, it will be polled
periodically through alarm. Interrupt is involved here. And then
VF will send I40E_VIRTCHNL_OP_GET_LINK_STAT message to
PF to query the status. The response is handled by interrupt
callback. Interrupt is involved here again. That's why bond
device cannot bring up.
This patch removes I40E_VIRTCHNL_OP_GET_LINK_STAT
message. Link status in VF driver will be updated when PF driver
notify it, and VF stores this link status locally. VF driver just
returns the local status when being required.
Fixes: 4861cde461 ("i40e: new poll mode driver")
Signed-off-by: Qiming Yang <qiming.yang@intel.com>
Acked-by: Jingjing Wu <jingjing.wu@intel.com>
Previously, link status interrupt in i40e is achieved by checking
LINK_STAT_CHANGE_MASK in PFINT_ICR0 register which is provided only
for diagnostic use. Instead, drivers need to get the link status
change notification by using LSE (Link Status Event).
This patch enables LSE and calls LSC callback when the event is
received. This patch also removes the processing on
LINK_STAT_CHANGE_MASK.
Fixes: 4861cde461 ("i40e: new poll mode driver")
Signed-off-by: Qiming Yang <qiming.yang@intel.com>
Acked-by: Jingjing Wu <jingjing.wu@intel.com>
Turning off S-TAG identification will impact floating VEB,
VFs can't communicate with each other.
This patch fixes this issue by judging whether floating
VEB is enabled, S-TAG identification will be turned off
only when floating VEB is disabled.
Fixes: 4d61120d5c ("net/i40e: fix dropping packets with ethertype 0x88A8")
Signed-off-by: Beilei Xing <beilei.xing@intel.com>
Acked-by: Jingjing Wu <jingjing.wu@intel.com>
Removing stopping LLDP in firmware is a workaround for a
known errata which can cause Rx hang. But the changing will
cause DCB configuration fails. That is because when LLDP is
enabled, the return value of i40e_init_dcb is success. But
following check just considered the case when LLDP agent
is disabled.
This patch fixes this issue.
Fixes: fcbd40d432 ("net/i40e: fix Rx hang when disable LLDP")
Signed-off-by: Jingjing Wu <jingjing.wu@intel.com>
Acked-by: Beilei Xing <beilei.xing@intel.com>
Some VF registers are using PF's name or address by mistake.
Although some of them are sharing the same addresses.
Fixes: 0198848a47 ("ixgbe: add access to specific device info")
Reported-by: Xuekun Hu <xuekun.hu@intel.com>
Signed-off-by: Wenzhuo Lu <wenzhuo.lu@intel.com>
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 <ananda@versa-networks.com>
Acked-by: Wenzhuo Lu <wenzhuo.lu@intel.com>
When queue number shrinks to 1 from X, the following code stops us
sending the multiple queue ctrl message:
if (nb_queues > 1) {
if (virtio_set_multiple_queues(dev, nb_queues) != 0)
return -EINVAL;
}
This ends up with still X queues being enabled, which is obviously
wrong. Fix it by replacing the check with a multiple queue enabled
or not check.
Fixes: 823ad64795 ("virtio: support multiple queues")
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
From the virtio spec of view, multiple-queue is always enabled/disabled
in queue pairs. DPDK somehow allows the case when Tx and Rx queue number
are different.
Currently, virtio PMD get the queue pair number from the nb_rx_queues
field, which could be an issue when Tx queue number > Rx queue number.
Say, 2 Tx queues and 1 Rx queues. This would end up with 1 quues being
enabled. Which is wrong.
The fix is straightforward. Just pick a bigger number and enable that many
of queues.
Fixes: 823ad64795 ("virtio: support multiple queues")
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
The "hw->started" field was introduced to stop touching queues
on restart. We never touches queues on restart any more, thus
it's safe to remove this flag.
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Reviewed-by: Maxime Coquelin <maxime.coquelin@redhat.com>
Invoking vtpci_reinit_complete() at port start stage doesn't make any
sense, instead, it should be done at the end of dev init stage.
So move it here.
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Reviewed-by: Maxime Coquelin <maxime.coquelin@redhat.com>
The only piece of code of virtio_dev_rxtx_start() is actually doing
queue configure/setup work. So, move it to corresponding queue_setup
callback.
Once that is done, virtio_dev_rxtx_start() becomes an empty function,
thus it's being removed.
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Reviewed-by: Maxime Coquelin <maxime.coquelin@redhat.com>
virtio_dev_vring_start() is actually doing the vring initiation job.
And the vring initiation job should be done at the dev init stage, as
stated with great details in former commit.
So move it there, and rename it to virtio_init_vring().
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Reviewed-by: Maxime Coquelin <maxime.coquelin@redhat.com>
Queue allocation should be done once, since the queue related info (such
as vring addreess) will only be informed to the vhost-user backend once
without virtio device reset.
That means, if you allocate queues again after the vhost-user negotiation,
the vhost-user backend will not be informed any more. Leading to a state
that the vring info mismatches between virtio PMD driver and vhost-backend:
the driver switches to the new address has just been allocated, while the
vhost-backend still sticks to the old address has been assigned in the init
stage.
Unfortunately, that is exactly how the virtio driver is coded so far: queue
allocation is done at queue_setup stage (when rte_eth_tx/rx_queue_setup is
invoked). This is wrong, because queue_setup can be invoked several times.
For example,
$ start_testpmd.sh ... --txq=1 --rxq=1 ...
> port stop 0
> port config all txq 1 # just trigger the queue_setup callback again
> port config all rxq 1
> port start 0
The right way to do is allocate the queues in the init stage, so that the
vring info could be persistent with the vhost-user backend.
Besides that, we should allocate max_queue pairs the device supports, but
not nr queue pairs firstly configured, to make following case work.
$ start_testpmd.sh ... --txq=1 --rxq=1 ...
> port stop 0
> port config all txq 2
> port config all rxq 2
> port start 0
Since the allocation is switched to init stage, the free should also
moved from the rx/tx_queue_release to dev close stage. That leading we
could do nothing an empty rx/tx_queue_release() implementation.
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Let rxq/txq/cq be the union field of the virtqueue struct. This would
simplifies the vq allocation a bit: we don't need calculate the vq_size
any more based on the queue type.
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Reviewed-by: Maxime Coquelin <maxime.coquelin@redhat.com>
Instead of setting up a queue memzone name like "port0_rxq0", "port0_txq0",
it could be simplified a bit to something like "port0_vq0", "port0_vq1" ...
Meanwhile, the code is also simplified a bit.
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Reviewed-by: Maxime Coquelin <maxime.coquelin@redhat.com>
This reverts commit 9a0615af77 ("virtio: fix restart"); conflict is
manually addressed.
Kyle reported an issue with above commit
qemu-kvm: Guest moved used index from 5 to 1
with following steps,
1) Start my virtio interfaces
2) Send some traffic into/out of the interfaces
3) Stop the interfaces
4) Start the interfaces
5) Send some more traffic
And here are some quotes from Kyle's analysis,
Prior to the patch, if an interface were stopped then started, without
restarting the application, the queues would be left as-is, because
hw->started would be set to 1. Now, calling stop sets hw->started to 0,
which means the next call to start will "touch the queues". This is the
unintended side-effect that causes the problem.
We should not touch the queues once the init is done, otherwise, the vring
state of virtio PMD driver and vhost-user would be inconsistent, leading
some issue like above.
Thus this patch is reverted.
Fixes: 9a0615af77 ("virtio: fix restart")
Reported-by: Kyle Larose <klarose@sandvine.com>
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Reviewed-by: Maxime Coquelin <maxime.coquelin@redhat.com>
Coverity detected this as an issue because internals->data will never be NULL,
then the check is not necessary.
Coverity issue: 137873
Fixes: d082c0395b ("ring: fix memory leak when detaching")
Signed-off-by: Mauricio Vasquez B <mauricio.vasquez@polito.it>
Acked-by: Ferruh Yigit <ferruh.yigit@intel.com>
