* Re: [PATCH] net/af_packet: initialize link interrupt callback queue
From: Ferruh Yigit @ 2016-12-21 15:30 UTC (permalink / raw)
To: Chas Williams, dev
In-Reply-To: <1481997835-23288-1-git-send-email-3chas3@gmail.com>
On 12/17/2016 6:03 PM, Chas Williams wrote:
> This patch initializes the eth_dev->link_intr_cbs queue which is
> used when af_packet is passed into rte_eth_ev_callback_register().
>
> Fixes: 4dc294158cac ("ethdev: support optional Rx and Tx callbacks")
>
> Signed-off-by: Chas Williams <3chas3@gmail.com>
Acked-by: Ferruh Yigit <ferruh.yigit@intel.com>
^ permalink raw reply
* Re: [PATCH v3 7/9] ethdev: Move filling of rte_eth_dev_info->pci_dev to dev_infos_get()
From: Jan Blunck @ 2016-12-21 15:35 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: dev, Shreyansh Jain, David Marchand
In-Reply-To: <20161220074100.7c9526ae@xeon-e3>
On Tue, Dec 20, 2016 at 4:41 PM, Stephen Hemminger
<stephen@networkplumber.org> wrote:
> On Tue, 20 Dec 2016 12:11:53 +0100
> Jan Blunck <jblunck@infradead.org> wrote:
>
>> Only the device itself can decide its PCI or not.
>>
>> Signed-off-by: Jan Blunck <jblunck@infradead.org>
>> ---
>> drivers/net/bnx2x/bnx2x_ethdev.c | 1 +
>> drivers/net/bnxt/bnxt_ethdev.c | 2 ++
>> drivers/net/cxgbe/cxgbe_ethdev.c | 2 ++
>> drivers/net/e1000/em_ethdev.c | 1 +
>> drivers/net/e1000/igb_ethdev.c | 2 ++
>> drivers/net/ena/ena_ethdev.c | 2 ++
>> drivers/net/enic/enic_ethdev.c | 1 +
>> drivers/net/fm10k/fm10k_ethdev.c | 1 +
>> drivers/net/i40e/i40e_ethdev.c | 1 +
>> drivers/net/i40e/i40e_ethdev_vf.c | 1 +
>> drivers/net/ixgbe/ixgbe_ethdev.c | 2 ++
>> drivers/net/mlx4/mlx4.c | 2 ++
>> drivers/net/mlx5/mlx5_ethdev.c | 2 ++
>> drivers/net/nfp/nfp_net.c | 1 +
>> drivers/net/qede/qede_ethdev.c | 1 +
>> drivers/net/szedata2/rte_eth_szedata2.c | 1 +
>> drivers/net/thunderx/nicvf_ethdev.c | 2 ++
>> drivers/net/virtio/virtio_ethdev.c | 1 +
>> drivers/net/vmxnet3/vmxnet3_ethdev.c | 2 ++
>> lib/librte_ether/rte_ethdev.c | 1 -
>> 20 files changed, 28 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/bnx2x/bnx2x_ethdev.c b/drivers/net/bnx2x/bnx2x_ethdev.c
>> index c331ccd..551dbad 100644
>> --- a/drivers/net/bnx2x/bnx2x_ethdev.c
>> +++ b/drivers/net/bnx2x/bnx2x_ethdev.c
>> @@ -431,6 +431,7 @@ static void
>> bnx2x_dev_infos_get(struct rte_eth_dev *dev, __rte_unused struct rte_eth_dev_info *dev_info)
>> {
>> struct bnx2x_softc *sc = dev->data->dev_private;
>> + dev_info->pci_dev = ETH_DEV_PCI_DEV(dev);
>> dev_info->max_rx_queues = sc->max_rx_queues;
>> dev_info->max_tx_queues = sc->max_tx_queues;
>> dev_info->min_rx_bufsize = BNX2X_MIN_RX_BUF_SIZE;
>> diff --git a/drivers/net/bnxt/bnxt_ethdev.c b/drivers/net/bnxt/bnxt_ethdev.c
>> index cd50f11..bf39fbe 100644
>> --- a/drivers/net/bnxt/bnxt_ethdev.c
>> +++ b/drivers/net/bnxt/bnxt_ethdev.c
>> @@ -303,6 +303,8 @@ static void bnxt_dev_info_get_op(struct rte_eth_dev *eth_dev,
>> struct bnxt *bp = (struct bnxt *)eth_dev->data->dev_private;
>> uint16_t max_vnics, i, j, vpool, vrxq;
>>
>> + dev_info->pci_dev = ETH_DEV_PCI_DEV(eth_dev);
>> +
>> /* MAC Specifics */
>> dev_info->max_mac_addrs = MAX_NUM_MAC_ADDR;
>> dev_info->max_hash_mac_addrs = 0;
>> diff --git a/drivers/net/cxgbe/cxgbe_ethdev.c b/drivers/net/cxgbe/cxgbe_ethdev.c
>> index 8bfdda8..8938b08 100644
>> --- a/drivers/net/cxgbe/cxgbe_ethdev.c
>> +++ b/drivers/net/cxgbe/cxgbe_ethdev.c
>> @@ -147,6 +147,8 @@ static void cxgbe_dev_info_get(struct rte_eth_dev *eth_dev,
>> .nb_align = 1,
>> };
>>
>> + device_info->pci_dev = ETH_DEV_PCI_DEV(eth_dev);
>> +
>> device_info->min_rx_bufsize = CXGBE_MIN_RX_BUFSIZE;
>> device_info->max_rx_pktlen = CXGBE_MAX_RX_PKTLEN;
>> device_info->max_rx_queues = max_queues;
>> diff --git a/drivers/net/e1000/em_ethdev.c b/drivers/net/e1000/em_ethdev.c
>> index 7f2f521..3d34e5b 100644
>> --- a/drivers/net/e1000/em_ethdev.c
>> +++ b/drivers/net/e1000/em_ethdev.c
>> @@ -1048,6 +1048,7 @@ eth_em_infos_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *dev_info)
>> {
>> struct e1000_hw *hw = E1000_DEV_PRIVATE_TO_HW(dev->data->dev_private);
>>
>> + dev_info->pci_dev = ETH_DEV_PCI_DEV(dev);
>> dev_info->min_rx_bufsize = 256; /* See BSIZE field of RCTL register. */
>> dev_info->max_rx_pktlen = em_get_max_pktlen(hw);
>> dev_info->max_mac_addrs = hw->mac.rar_entry_count;
>> diff --git a/drivers/net/e1000/igb_ethdev.c b/drivers/net/e1000/igb_ethdev.c
>> index b25c66e..7d77561 100644
>> --- a/drivers/net/e1000/igb_ethdev.c
>> +++ b/drivers/net/e1000/igb_ethdev.c
>> @@ -1983,6 +1983,7 @@ eth_igb_infos_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *dev_info)
>> {
>> struct e1000_hw *hw = E1000_DEV_PRIVATE_TO_HW(dev->data->dev_private);
>>
>> + dev_info->pci_dev = ETH_DEV_PCI_DEV(dev);
>> dev_info->min_rx_bufsize = 256; /* See BSIZE field of RCTL register. */
>> dev_info->max_rx_pktlen = 0x3FFF; /* See RLPML register. */
>> dev_info->max_mac_addrs = hw->mac.rar_entry_count;
>> @@ -2111,6 +2112,7 @@ eth_igbvf_infos_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *dev_info)
>> {
>> struct e1000_hw *hw = E1000_DEV_PRIVATE_TO_HW(dev->data->dev_private);
>>
>> + dev_info->pci_dev = ETH_DEV_PCI_DEV(dev);
>> dev_info->min_rx_bufsize = 256; /* See BSIZE field of RCTL register. */
>> dev_info->max_rx_pktlen = 0x3FFF; /* See RLPML register. */
>> dev_info->max_mac_addrs = hw->mac.rar_entry_count;
>> diff --git a/drivers/net/ena/ena_ethdev.c b/drivers/net/ena/ena_ethdev.c
>> index c17d969..051275e 100644
>> --- a/drivers/net/ena/ena_ethdev.c
>> +++ b/drivers/net/ena/ena_ethdev.c
>> @@ -1436,6 +1436,8 @@ static void ena_infos_get(struct rte_eth_dev *dev,
>> ena_dev = &adapter->ena_dev;
>> ena_assert_msg(ena_dev != NULL, "Uninitialized device");
>>
>> + dev_info->pci_dev = ETH_DEV_PCI_DEV(dev);
>> +
>> dev_info->speed_capa =
>> ETH_LINK_SPEED_1G |
>> ETH_LINK_SPEED_2_5G |
>> diff --git a/drivers/net/enic/enic_ethdev.c b/drivers/net/enic/enic_ethdev.c
>> index 553a88e..bb5dfe6 100644
>> --- a/drivers/net/enic/enic_ethdev.c
>> +++ b/drivers/net/enic/enic_ethdev.c
>> @@ -459,6 +459,7 @@ static void enicpmd_dev_info_get(struct rte_eth_dev *eth_dev,
>> struct enic *enic = pmd_priv(eth_dev);
>>
>> ENICPMD_FUNC_TRACE();
>> + device_info->pci_dev = ETH_DEV_PCI_DEV(eth_dev);
>> /* Scattered Rx uses two receive queues per rx queue exposed to dpdk */
>> device_info->max_rx_queues = enic->conf_rq_count / 2;
>> device_info->max_tx_queues = enic->conf_wq_count;
>> diff --git a/drivers/net/fm10k/fm10k_ethdev.c b/drivers/net/fm10k/fm10k_ethdev.c
>> index e1250f6..5d0bce5 100644
>> --- a/drivers/net/fm10k/fm10k_ethdev.c
>> +++ b/drivers/net/fm10k/fm10k_ethdev.c
>> @@ -1392,6 +1392,7 @@ fm10k_dev_infos_get(struct rte_eth_dev *dev,
>>
>> PMD_INIT_FUNC_TRACE();
>>
>> + dev_info->pci_dev = ETH_DEV_PCI_DEV(dev);
>> dev_info->min_rx_bufsize = FM10K_MIN_RX_BUF_SIZE;
>> dev_info->max_rx_pktlen = FM10K_MAX_PKT_SIZE;
>> dev_info->max_rx_queues = hw->mac.max_queues;
>> diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
>> index 8a63a8c..29c0277 100644
>> --- a/drivers/net/i40e/i40e_ethdev.c
>> +++ b/drivers/net/i40e/i40e_ethdev.c
>> @@ -2583,6 +2583,7 @@ i40e_dev_info_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *dev_info)
>> struct i40e_hw *hw = I40E_DEV_PRIVATE_TO_HW(dev->data->dev_private);
>> struct i40e_vsi *vsi = pf->main_vsi;
>>
>> + dev_info->pci_dev = ETH_DEV_PCI_DEV(dev);
>> dev_info->max_rx_queues = vsi->nb_qps;
>> dev_info->max_tx_queues = vsi->nb_qps;
>> dev_info->min_rx_bufsize = I40E_BUF_SIZE_MIN;
>> diff --git a/drivers/net/i40e/i40e_ethdev_vf.c b/drivers/net/i40e/i40e_ethdev_vf.c
>> index 781e658..caef72c 100644
>> --- a/drivers/net/i40e/i40e_ethdev_vf.c
>> +++ b/drivers/net/i40e/i40e_ethdev_vf.c
>> @@ -2217,6 +2217,7 @@ i40evf_dev_info_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *dev_info)
>> struct i40e_vf *vf = I40EVF_DEV_PRIVATE_TO_VF(dev->data->dev_private);
>>
>> memset(dev_info, 0, sizeof(*dev_info));
>> + dev_info->pci_dev = ETH_DEV_PCI_DEV(dev);
>> dev_info->max_rx_queues = vf->vsi_res->num_queue_pairs;
>> dev_info->max_tx_queues = vf->vsi_res->num_queue_pairs;
>> dev_info->min_rx_bufsize = I40E_BUF_SIZE_MIN;
>> diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
>> index f17da46..c88b7bf 100644
>> --- a/drivers/net/ixgbe/ixgbe_ethdev.c
>> +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
>> @@ -3043,6 +3043,7 @@ ixgbe_dev_info_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *dev_info)
>> struct rte_eth_conf *dev_conf = &dev->data->dev_conf;
>> struct rte_pci_device *pci_dev = ETH_DEV_PCI_DEV(dev);
>>
>> + dev_info->pci_dev = ETH_DEV_PCI_DEV(dev);
>> dev_info->max_rx_queues = (uint16_t)hw->mac.max_rx_queues;
>> dev_info->max_tx_queues = (uint16_t)hw->mac.max_tx_queues;
>> if (RTE_ETH_DEV_SRIOV(dev).active == 0) {
>> @@ -3175,6 +3176,7 @@ ixgbevf_dev_info_get(struct rte_eth_dev *dev,
>> struct ixgbe_hw *hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
>> struct rte_pci_device *pci_dev = ETH_DEV_PCI_DEV(dev);
>>
>> + dev_info->pci_dev = ETH_DEV_PCI_DEV(dev);
>> dev_info->max_rx_queues = (uint16_t)hw->mac.max_rx_queues;
>> dev_info->max_tx_queues = (uint16_t)hw->mac.max_tx_queues;
>> dev_info->min_rx_bufsize = 1024; /* cf BSIZEPACKET in SRRCTL reg */
>> diff --git a/drivers/net/mlx4/mlx4.c b/drivers/net/mlx4/mlx4.c
>> index da61a85..5455fea 100644
>> --- a/drivers/net/mlx4/mlx4.c
>> +++ b/drivers/net/mlx4/mlx4.c
>> @@ -4421,6 +4421,8 @@ mlx4_dev_infos_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *info)
>> unsigned int max;
>> char ifname[IF_NAMESIZE];
>>
>> + info->pci_dev = ETH_DEV_PCI_DEV(dev);
>> +
>> if (priv == NULL)
>> return;
>> priv_lock(priv);
>> diff --git a/drivers/net/mlx5/mlx5_ethdev.c b/drivers/net/mlx5/mlx5_ethdev.c
>> index c0f73e9..489a4f6 100644
>> --- a/drivers/net/mlx5/mlx5_ethdev.c
>> +++ b/drivers/net/mlx5/mlx5_ethdev.c
>> @@ -562,6 +562,8 @@ mlx5_dev_infos_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *info)
>> unsigned int max;
>> char ifname[IF_NAMESIZE];
>>
>> + info->pci_dev = ETH_DEV_PCI_DEV(dev);
>> +
>> priv_lock(priv);
>> /* FIXME: we should ask the device for these values. */
>> info->min_rx_bufsize = 32;
>> diff --git a/drivers/net/nfp/nfp_net.c b/drivers/net/nfp/nfp_net.c
>> index 7299fad..c49d38a 100644
>> --- a/drivers/net/nfp/nfp_net.c
>> +++ b/drivers/net/nfp/nfp_net.c
>> @@ -1008,6 +1008,7 @@ nfp_net_infos_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *dev_info)
>>
>> hw = NFP_NET_DEV_PRIVATE_TO_HW(dev->data->dev_private);
>>
>> + dev_info->pci_dev = ETH_DEV_PCI_DEV(dev);
>> dev_info->driver_name = dev->driver->pci_drv.driver.name;
>> dev_info->max_rx_queues = (uint16_t)hw->max_rx_queues;
>> dev_info->max_tx_queues = (uint16_t)hw->max_tx_queues;
>> diff --git a/drivers/net/qede/qede_ethdev.c b/drivers/net/qede/qede_ethdev.c
>> index 959ff0f..2c4de92 100644
>> --- a/drivers/net/qede/qede_ethdev.c
>> +++ b/drivers/net/qede/qede_ethdev.c
>> @@ -652,6 +652,7 @@ qede_dev_info_get(struct rte_eth_dev *eth_dev,
>>
>> PMD_INIT_FUNC_TRACE(edev);
>>
>> + dev_info->pci_dev = ETH_DEV_PCI_DEV(eth_dev);
>> dev_info->min_rx_bufsize = (uint32_t)(ETHER_MIN_MTU +
>> QEDE_ETH_OVERHEAD);
>> dev_info->max_rx_pktlen = (uint32_t)ETH_TX_MAX_NON_LSO_PKT_LEN;
>> diff --git a/drivers/net/szedata2/rte_eth_szedata2.c b/drivers/net/szedata2/rte_eth_szedata2.c
>> index 6d80a5b..6356257 100644
>> --- a/drivers/net/szedata2/rte_eth_szedata2.c
>> +++ b/drivers/net/szedata2/rte_eth_szedata2.c
>> @@ -1030,6 +1030,7 @@ eth_dev_info(struct rte_eth_dev *dev,
>> struct rte_eth_dev_info *dev_info)
>> {
>> struct pmd_internals *internals = dev->data->dev_private;
>> + dev_info->pci_dev = ETH_DEV_PCI_DEV(dev);
>> dev_info->if_index = 0;
>> dev_info->max_mac_addrs = 1;
>> dev_info->max_rx_pktlen = (uint32_t)-1;
>> diff --git a/drivers/net/thunderx/nicvf_ethdev.c b/drivers/net/thunderx/nicvf_ethdev.c
>> index 099b252..daac853 100644
>> --- a/drivers/net/thunderx/nicvf_ethdev.c
>> +++ b/drivers/net/thunderx/nicvf_ethdev.c
>> @@ -1339,6 +1339,8 @@ nicvf_dev_info_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *dev_info)
>>
>> PMD_INIT_FUNC_TRACE();
>>
>> + dev_info->pci_dev = pci_dev;
>> +
>> dev_info->min_rx_bufsize = ETHER_MIN_MTU;
>> dev_info->max_rx_pktlen = NIC_HW_MAX_FRS;
>> dev_info->max_rx_queues =
>> diff --git a/drivers/net/virtio/virtio_ethdev.c b/drivers/net/virtio/virtio_ethdev.c
>> index 023101d..2eb6a06 100644
>> --- a/drivers/net/virtio/virtio_ethdev.c
>> +++ b/drivers/net/virtio/virtio_ethdev.c
>> @@ -1625,6 +1625,7 @@ virtio_dev_info_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *dev_info)
>> uint64_t tso_mask;
>> struct virtio_hw *hw = dev->data->dev_private;
>>
>> + dev_info->pci_dev = hw->dev;
>> dev_info->max_rx_queues =
>> RTE_MIN(hw->max_queue_pairs, VIRTIO_MAX_RX_QUEUES);
>> dev_info->max_tx_queues =
>> diff --git a/drivers/net/vmxnet3/vmxnet3_ethdev.c b/drivers/net/vmxnet3/vmxnet3_ethdev.c
>> index bcb3751..f7c0382 100644
>> --- a/drivers/net/vmxnet3/vmxnet3_ethdev.c
>> +++ b/drivers/net/vmxnet3/vmxnet3_ethdev.c
>> @@ -709,6 +709,8 @@ static void
>> vmxnet3_dev_info_get(__rte_unused struct rte_eth_dev *dev,
>> struct rte_eth_dev_info *dev_info)
>> {
>> + dev_info->pci_dev = ETH_DEV_PCI_DEV(dev);
>> +
>> dev_info->max_rx_queues = VMXNET3_MAX_RX_QUEUES;
>> dev_info->max_tx_queues = VMXNET3_MAX_TX_QUEUES;
>> dev_info->min_rx_bufsize = 1518 + RTE_PKTMBUF_HEADROOM;
>> diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
>> index fde8112..4288577 100644
>> --- a/lib/librte_ether/rte_ethdev.c
>> +++ b/lib/librte_ether/rte_ethdev.c
>> @@ -1556,7 +1556,6 @@ rte_eth_dev_info_get(uint8_t port_id, struct rte_eth_dev_info *dev_info)
>>
>> RTE_FUNC_PTR_OR_RET(*dev->dev_ops->dev_infos_get);
>> (*dev->dev_ops->dev_infos_get)(dev, dev_info);
>> - dev_info->pci_dev = dev->pci_dev;
>> dev_info->driver_name = dev->data->drv_name;
>> dev_info->nb_rx_queues = dev->data->nb_rx_queues;
>> dev_info->nb_tx_queues = dev->data->nb_tx_queues;
>
>
> If dev_info_get sets a pointer to device (rather than pci_dev) then it can
> stay in generic code.
True. But as mentioned before I still think that the low-level device
shouldn't get exposed via rte_eth_dev_info. Having the generic
rte_device there is even more questionable if you ask me.
^ permalink raw reply
* Re: [PATCH v3 02/12] eal/bus: introduce bus abstraction
From: Jan Blunck @ 2016-12-21 15:38 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Shreyansh Jain, dev, David Marchand, Thomas Monjalon,
Ferruh Yigit, jianbo.liu
In-Reply-To: <20161220091156.4442cb07@xeon-e3>
On Tue, Dec 20, 2016 at 6:11 PM, Stephen Hemminger
<stephen@networkplumber.org> wrote:
> On Tue, 20 Dec 2016 14:17:14 +0100
> Jan Blunck <jblunck@infradead.org> wrote:
>
>> On Fri, Dec 16, 2016 at 2:10 PM, Shreyansh Jain <shreyansh.jain@nxp.com> wrote:
>> > This patch introduces the rte_bus abstraction for devices and drivers in
>> > EAL framework. The model is:
>> > - One or more buses are connected to a CPU (or core)
>> > - One or more devices are conneted to a Bus
>> > - Drivers are running instances which manage one or more devices
>> > - Bus is responsible for identifying devices (and interrupt propogation)
>> > - Driver is responsible for initializing the device
>> >
>> > This patch adds a 'rte_bus' class which rte_driver and rte_device refer.
>> > This way, each device (rte_xxx_device) would have reference to the bus
>> > it is based on. As well as, each driver (rte_xxx_driver) would have link
>> > to the bus and devices on it for servicing.
>> >
>> > __ rte_bus_list
>> > /
>> > +----------'---+
>> > |rte_bus |
>> > | driver_list------> List of rte_bus specific
>> > | device_list---- devices
>> > | | `-> List of rte_bus associated
>> > | | drivers
>> > +--|------|----+
>> > _________/ \_________
>> > +--------/----+ +-\---------------+
>> > |rte_device | |rte_driver |
>> > | rte_bus | | rte_bus |
>> > | rte_driver | | ... |
>> > | ... | +---------...-----+
>> > | | |||
>> > +---||--------+ |||
>> > || |||
>> > | \ \\\
>> > | \_____________ \\\
>> > | \ |||
>> > +------|---------+ +----|----------+ |||
>> > |rte_pci_device | |rte_xxx_device | |||
>> > | .... | | .... | |||
>> > +----------------+ +---------------+ / | \
>> > / | \
>> > _____________________/ / \
>> > / ___/ \
>> > +-------------'--+ +------------'---+ +--'------------+
>> > |rte_pci_driver | |rte_vdev_driver | |rte_xxx_driver |
>> > | .... | | .... | | .... |
>> > +----------------+ +----------------+ +---------------+
>> >
>> > This patch only enables the bus references on rte_driver and rte_driver.
>> > EAL wide global device and driver list continue to exist until an instance
>> > of bus is added in subsequent patches.
>> >
>> > This patch also introduces RTE_REGISTER_BUS macro on the lines of
>> > RTE_PMD_REGISTER_XXX. Key difference is that the constructor priority has
>> > been explicitly set to 101 so as to execute bus registration before PMD.
>> >
>> > Signed-off-by: Shreyansh Jain <shreyansh.jain@nxp.com>
>> >
>
> Ok, but let's keep this as bus type not bus. It gets really hard and complex
> to enumerate all layers of PCI bus and bridges.
As far as I understand it this isn't the intention to replicate the
hierarchy of buses we have in the kernel. The PCI bus in this case
becomes a list of PCI devices.
^ permalink raw reply
* Re: [PATCH v2 00/12] Add crypto PMD optimized for ARMv8
From: Declan Doherty @ 2016-12-21 15:34 UTC (permalink / raw)
To: Jerin Jacob, Zbigniew Bodek; +Cc: Bruce Richardson, pablo.de.lara.guarch, dev
In-Reply-To: <20161208174550.GA4966@svelivela-lt.caveonetworks.com>
On 08/12/16 17:45, Jerin Jacob wrote:
> On Thu, Dec 08, 2016 at 12:32:52PM +0100, Zbigniew Bodek wrote:
>> On 08.12.2016 11:24, Bruce Richardson wrote:
>>> On Tue, Dec 06, 2016 at 06:32:53PM -0800, zbigniew.bodek@caviumnetworks.com wrote:
>>>> From: Zbigniew Bodek <zbigniew.bodek@caviumnetworks.com>
>>>>
>>>> Introduce crypto poll mode driver using ARMv8
>>>> cryptographic extensions. This PMD is optimized
>>>> to provide performance boost for chained
>>>> crypto operations processing, such as:
>>>> * encryption + HMAC generation
>>>> * decryption + HMAC validation.
>>>> In particular, cipher only or hash only
>>>> operations are not provided.
>>>> Performance gain can be observed in tests
>>>> against OpenSSL PMD which also uses ARM
>>>> crypto extensions for packets processing.
>>>>
>>> Hi,
>>>
>>> great to see more crypto drivers coming into DPDK, thanks.
>>>
>>> Question: do you know if this code would have any export compliance
>>> implications for DPDK - or for those repackaging DPDK? Up till now, all
>>> the crypto code used by DPDK was actually packaged in separate libraries
>>> that were re-used, meaning that DPDK didn't contain any crypto
>>> algorithms itself.
>>>
>>
>> Hello Bruce,
>>
>> I don't know to be honest. I didn't know the reasoning behind not including
>> crypto code for Intel for example. I thought it was due to licensing and
>> code control rather than export compliance.
>>
>> Maybe someone from the DPDK community will know what are the constraints
>> related to including crypto algorithms to DPDK.
>
> One of the primary reason why we thought of going with this approach is
> for out of the box "distribution" enablement. We thought, if the core crypto
> algorithm sits in some git-hub code or public hosted tarball then the
> PMD will never be added to standard distributions and which is a setback
> for armv8 server ecosystem.
>
> Having said that and as Zbigniew mentioned, We are open for revisiting
> the crypto core algorithm and PMD split if there are community concerns
> about export compliance. Let us know.
>
> Jerin
>
>>
>> Kind regards
>> Zbigniew
Hey Jerin/Zbigniew,
as Bruce said it's great to see you contributing to the crypto ecosystem
in DPDK. I don't know if the export compliance with the core crypto code
is an issue or not, that's definitely not my area of expertise, but I do
have some concern which I think it relates somewhat to Thomas questions
regarding implementing the core crypto algorithms in C rather than assembly.
I wonder is there the expertise within the DPDK community to
review/maintain the core crypto code in terms of both the assembly code
itself and also the details of the crypto algorithm's implementations
themselves. I know I wouldn't feel I have the knowledge/expertise to be
able to review the core crypto algorithm's implementations and the
assembly code itself and sign-off on them.
I understand the advantage of having the code integrated directly into
DPDK for packaging etc but this also puts the ownest on the DPDK
community for the correctness of the underlying implementation of a
particular algorithm. I think the approach of a separate library removes
this responsibility from the community and places it on the distributor
of the core crypto library.
Declan
^ permalink raw reply
* Why IP_PIPELINE is faster than L2FWD
From: Royce Niu @ 2016-12-21 16:18 UTC (permalink / raw)
To: dev
Hi all,
I tested default L2FWD and IP_PIPELINE (pass-through). The throughput of
IP_PIPELINE is higher immensely.
There are only two virtual NICs in KVM. The experiment is just moving
packet from vNIC0 to vNIC1. I think the function is so simple. Why L2FWD
is much slower?
How can I improve L2FWD, to make L2FWD faster?
Thanks!
--
Regards,
Royce
^ permalink raw reply
* Re: [PATCH v2 00/25] Generic flow API (rte_flow)
From: Simon Horman @ 2016-12-21 16:19 UTC (permalink / raw)
To: Adrien Mazarguil; +Cc: dev
In-Reply-To: <cover.1481903839.git.adrien.mazarguil@6wind.com>
On Fri, Dec 16, 2016 at 05:24:57PM +0100, Adrien Mazarguil wrote:
> As previously discussed in RFC v1 [1], RFC v2 [2], with changes
> described in [3] (also pasted below), here is the first non-draft series
> for this new API.
>
> Its capabilities are so generic that its name had to be vague, it may be
> called "Generic flow API", "Generic flow interface" (possibly shortened
> as "GFI") to refer to the name of the new filter type, or "rte_flow" from
> the prefix used for its public symbols. I personally favor the latter.
>
> While it is currently meant to supersede existing filter types in order for
> all PMDs to expose a common filtering/classification interface, it may
> eventually evolve to cover the following ideas as well:
>
> - Rx/Tx offloads configuration through automatic offloads for specific
> packets, e.g. performing checksum on TCP packets could be expressed with
> an egress rule with a TCP pattern and a kind of checksum action.
>
> - RSS configuration (already defined actually). Could be global or per rule
> depending on hardware capabilities.
>
> - Switching configuration for devices with many physical ports; rules doing
> both ingress and egress could even be used to completely bypass software
> if supported by hardware.
Hi Adrien,
thanks for this valuable work.
I would like to ask some high level questions on the proposal.
I apologise in advance if any of these questions are based on a
misunderstanding on my part.
* I am wondering about provisions for actions to modify packet data or
metadata. I do see support for marking packets. Is the implication of
this that the main focus is to provide a mechanism for classification
with the assumption that any actions - other than drop and variants of
output - would be performed elsewhere?
If so I would observe that this seems somewhat limiting in the case of
hardware that can perform a richer set of actions. And seems particularly
limiting on egress as there doesn't seem anywhere else that other actions
could be performed after classification is performed by this API.
* I am curious to know what considerations have been given to supporting support for tunnelling (encapsulation and decapsulation of e.g. VXLAN),
tagging (pushing and popping e.g. VLANs), and labels (pushing or popping
e.g. MPLS).
Such features seem would useful for application of this work in a variety
of situations including overlay networks and VNFs.
* I am wondering if any thought has gone into supporting matching on the
n-th instance of a field that may appear more than once: e.g. VLAN tag.
With the above questions in mind I am curious to know what use-cases
the proposal is targeted at.
^ permalink raw reply
* Re: [PATCH v2 1/7] pci: If a driver's probe function fails, unmap resources.
From: Thomas Monjalon @ 2016-12-21 16:19 UTC (permalink / raw)
To: Shreyansh Jain, Ben Walker; +Cc: dev
In-Reply-To: <fc99600c-9a96-698f-4065-459b0b1dcb26@nxp.com>
2016-11-25 14:51, Shreyansh Jain:
> On Thursday 24 November 2016 01:37 AM, Ben Walker wrote:
> > If resources were mapped prior to probe, unmap them
> > if probe fails.
> >
> > This does not handle the case where the kernel driver was
> > forcibly unbound prior to probe.
> >
> > Signed-off-by: Ben Walker <benjamin.walker@intel.com>
>
> Acked-by: Shreyansh Jain <shreyansh.jain@nxp.com>
The 3 first patches of this series seems good and easy to agree,
except some minor nits.
Please Ben or Shreyansh, could you respin only them to help make
progress before applying a PCI/bus rework from Shreyansh?
As soon as one of you shoot a partial v3, I'll apply them.
Thanks
^ permalink raw reply
* Re: [PATCH v4 14/23] qede: localize mapping of eth_dev to pci
From: Harish Patil @ 2016-12-21 16:35 UTC (permalink / raw)
To: Jan Blunck, dev@dpdk.org
Cc: shreyansh.jain@nxp.com, david.marchand@6wind.com,
stephen@networkplumber.org
In-Reply-To: <1482332986-7599-15-git-send-email-jblunck@infradead.org>
>
>This simplifies later changes to ethdev.
>
>Signed-off-by: Jan Blunck <jblunck@infradead.org>
>---
> drivers/net/qede/qede_ethdev.c | 18 +++++++++---------
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
>diff --git a/drivers/net/qede/qede_ethdev.c
>b/drivers/net/qede/qede_ethdev.c
>index d106dd0..a50bd5f 100644
>--- a/drivers/net/qede/qede_ethdev.c
>+++ b/drivers/net/qede/qede_ethdev.c
>@@ -175,14 +175,14 @@ static void qede_interrupt_action(struct ecore_hwfn
>*p_hwfn)
> }
>
> static void
>-qede_interrupt_handler(__rte_unused struct rte_intr_handle *handle, void
>*param)
>+qede_interrupt_handler(struct rte_intr_handle *handle, void *param)
> {
> struct rte_eth_dev *eth_dev = (struct rte_eth_dev *)param;
> struct qede_dev *qdev = eth_dev->data->dev_private;
> struct ecore_dev *edev = &qdev->edev;
>
> qede_interrupt_action(ECORE_LEADING_HWFN(edev));
>- if (rte_intr_enable(ð_dev->pci_dev->intr_handle))
>+ if (rte_intr_enable(handle))
> DP_ERR(edev, "rte_intr_enable failed\n");
> }
>
>@@ -809,6 +809,7 @@ static void qede_poll_sp_sb_cb(void *param)
>
> static void qede_dev_close(struct rte_eth_dev *eth_dev)
> {
>+ struct rte_pci_device *pci_dev = eth_dev->pci_dev;
> struct qede_dev *qdev = QEDE_INIT_QDEV(eth_dev);
> struct ecore_dev *edev = QEDE_INIT_EDEV(qdev);
> int rc;
>@@ -835,9 +836,9 @@ static void qede_dev_close(struct rte_eth_dev
>*eth_dev)
>
> qdev->ops->common->remove(edev);
>
>- rte_intr_disable(ð_dev->pci_dev->intr_handle);
>+ rte_intr_disable(&pci_dev->intr_handle);
>
>- rte_intr_callback_unregister(ð_dev->pci_dev->intr_handle,
>+ rte_intr_callback_unregister(&pci_dev->intr_handle,
> qede_interrupt_handler, (void *)eth_dev);
>
> if (edev->num_hwfns > 1)
>@@ -1403,7 +1404,8 @@ static int qede_common_dev_init(struct rte_eth_dev
>*eth_dev, bool is_vf)
> /* Extract key data structures */
> adapter = eth_dev->data->dev_private;
> edev = &adapter->edev;
>- pci_addr = eth_dev->pci_dev->addr;
>+ pci_dev = eth_dev->pci_dev;
>+ pci_addr = pci_dev->addr;
>
> PMD_INIT_FUNC_TRACE(edev);
>
>@@ -1420,8 +1422,6 @@ static int qede_common_dev_init(struct rte_eth_dev
>*eth_dev, bool is_vf)
> return 0;
> }
>
>- pci_dev = eth_dev->pci_dev;
>-
> rte_eth_copy_pci_info(eth_dev, pci_dev);
>
> qed_ops = qed_get_eth_ops();
>@@ -1442,10 +1442,10 @@ static int qede_common_dev_init(struct
>rte_eth_dev *eth_dev, bool is_vf)
>
> qede_update_pf_params(edev);
>
>- rte_intr_callback_register(ð_dev->pci_dev->intr_handle,
>+ rte_intr_callback_register(&pci_dev->intr_handle,
> qede_interrupt_handler, (void *)eth_dev);
>
>- if (rte_intr_enable(ð_dev->pci_dev->intr_handle)) {
>+ if (rte_intr_enable(&pci_dev->intr_handle)) {
> DP_ERR(edev, "rte_intr_enable() failed\n");
> return -ENODEV;
> }
>--
>2.7.4
>
>
Acked-by: Harish Patil <harish.patil@qlogic.com>
^ permalink raw reply
* Re: [PATCH v4 12/23] bnx2x: localize mapping from eth_dev to pci
From: Harish Patil @ 2016-12-21 16:35 UTC (permalink / raw)
To: Jan Blunck, dev@dpdk.org
Cc: shreyansh.jain@nxp.com, david.marchand@6wind.com,
stephen@networkplumber.org
In-Reply-To: <1482332986-7599-13-git-send-email-jblunck@infradead.org>
>
>Use device private information to minimize the places that assume eth_dev
>contains pci_dev.
>
>Signed-off-by: Jan Blunck <jblunck@infradead.org>
>---
> drivers/net/bnx2x/bnx2x_ethdev.c | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
>diff --git a/drivers/net/bnx2x/bnx2x_ethdev.c
>b/drivers/net/bnx2x/bnx2x_ethdev.c
>index 0eae433..ef2026a 100644
>--- a/drivers/net/bnx2x/bnx2x_ethdev.c
>+++ b/drivers/net/bnx2x/bnx2x_ethdev.c
>@@ -119,12 +119,12 @@ bnx2x_interrupt_action(struct rte_eth_dev *dev)
> }
>
> static __rte_unused void
>-bnx2x_interrupt_handler(__rte_unused struct rte_intr_handle *handle,
>void *param)
>+bnx2x_interrupt_handler(struct rte_intr_handle *handle, void *param)
> {
> struct rte_eth_dev *dev = (struct rte_eth_dev *)param;
>
> bnx2x_interrupt_action(dev);
>- rte_intr_enable(&(dev->pci_dev->intr_handle));
>+ rte_intr_enable(handle);
> }
>
> /*
>@@ -187,10 +187,10 @@ bnx2x_dev_start(struct rte_eth_dev *dev)
> }
>
> if (IS_PF(sc)) {
>- rte_intr_callback_register(&(dev->pci_dev->intr_handle),
>+ rte_intr_callback_register(&sc->pci_dev->intr_handle,
> bnx2x_interrupt_handler, (void *)dev);
>
>- if(rte_intr_enable(&(dev->pci_dev->intr_handle)))
>+ if (rte_intr_enable(&sc->pci_dev->intr_handle))
> PMD_DRV_LOG(ERR, "rte_intr_enable failed");
> }
>
>@@ -215,8 +215,8 @@ bnx2x_dev_stop(struct rte_eth_dev *dev)
> PMD_INIT_FUNC_TRACE();
>
> if (IS_PF(sc)) {
>- rte_intr_disable(&(dev->pci_dev->intr_handle));
>- rte_intr_callback_unregister(&(dev->pci_dev->intr_handle),
>+ rte_intr_disable(&sc->pci_dev->intr_handle);
>+ rte_intr_callback_unregister(&sc->pci_dev->intr_handle,
> bnx2x_interrupt_handler, (void *)dev);
> }
>
>--
>2.7.4
>
>
Acked-by: Harish Patil <harish.patil@qlogic.com>
^ permalink raw reply
* Re: [PATCH v2 1/2] Clear eth_dev->data in rte_eth_dev_allocate()
From: Thomas Monjalon @ 2016-12-21 16:39 UTC (permalink / raw)
To: Jan Blunck; +Cc: dev, Ferruh Yigit
In-Reply-To: <fe779f25-40ae-8e00-38e8-e60227da7eff@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>
Both patches applied, thanks
^ permalink raw reply
* Re: [PATCH] net/af_packet: initialize link interrupt callback queue
From: Ferruh Yigit @ 2016-12-21 16:50 UTC (permalink / raw)
To: Chas Williams, dev
In-Reply-To: <fb2b1e42-2ab9-2880-88df-9b8a6fde8d14@intel.com>
On 12/21/2016 3:30 PM, Ferruh Yigit wrote:
> On 12/17/2016 6:03 PM, Chas Williams wrote:
>> This patch initializes the eth_dev->link_intr_cbs queue which is
>> used when af_packet is passed into rte_eth_ev_callback_register().
>>
>> Fixes: 4dc294158cac ("ethdev: support optional Rx and Tx callbacks")
>>
>> Signed-off-by: Chas Williams <3chas3@gmail.com>
>
> Acked-by: Ferruh Yigit <ferruh.yigit@intel.com>
>
The commit that just applied solves the issue that this patch targets:
http://dpdk.org/browse/dpdk/commit/?id=75aca7997e57b017
I am updating this patch as rejected.
Thanks,
ferruh
^ permalink raw reply
* Re: [PATCH v2 00/30] update ixgbe shared code to version 16.11.21
From: Ferruh Yigit @ 2016-12-21 17:20 UTC (permalink / raw)
To: Wei Dai, dev; +Cc: helin.zhang, konstantin.ananyev
In-Reply-To: <1482313694-31602-1-git-send-email-wei.dai@intel.com>
On 12/21/2016 9:47 AM, Wei Dai wrote:
> update ixgbe shared code to version 16.11.21 .
> v2 changes:
> modify subject line and message body of git log according to
> feedbacks from communtiy.
>
> split the 24th patch into 2 separate ones.
> the 24th of v1 is net/ixgbe/base: add EEE support for DNL-controlled PHYs
> the 24th of v2 is net/ixgbe/base: add EEE support for some PHYs
> the 25th of v2 is net/ixgbe/base: remove unused enum type
>
> correct RAEDME
>
> Wei Dai (30):
> net/ixgbe/base: fix PHY reset check for x550em-ext
> net/ixgbe/base: fix clearing SAN MAC address
> net/ixgbe/base: use fast MDIO for non-10G devices
> net/ixgbe/base: fix PHY identification for x550a
> net/ixgbe/base: clean up X557 link status check
> net/ixgbe/base: add driver version to firmware
> net/ixgbe/base: store link active LED
> net/ixgbe/base: cleanup X540 checksum calculation
> net/ixgbe/base: enable LASI only for X552 devices
> net/ixgbe/base: limit iXFI setup to X552 devices
> net/ixgbe/base: fix getting PHY type for some x550 devices
> net/ixgbe/base: fix SGMII link setup for M88 PHYs
> net/ixgbe/base: cleanup dead EEE code
> net/ixgbe/base: fix setting unsupported autoneg speeds
> net/ixgbe/base: support FW commands to control some PHYs
> net/ixgbe/base: use FW commands to control some PHYs
> net/ixgbe/base: support busy SGMII register reads
> net/ixgbe/base: include new speeds in VFLINK interpretation
> net/ixgbe/base: limit 5Gb support to X550 devices
> net/ixgbe/base: add physical layer options for FW PHY type
> net/ixgbe/base: remove unneeded MAC type check
> net/ixgbe/base: remove unused PHY ID
> net/ixgbe/base: update FW PHY flow control
> net/ixgbe/base: add EEE support for some PHYs
> net/ixgbe/base: remove unused enum type
> net/ixgbe/base: fix IXGBE LSWFW register
> net/ixgbe/base: remove unused EEE code
> net/ixgbe/base: add write flush required by Inphi PHY
> net/ixgbe/base: report physical layer for SGMII PHY type
> net/ixgbe/base: update shared code version to 2016.11.21
<...>
Series applied to dpdk-next-net/master, thanks.
^ permalink raw reply
* Re: [PATCH v2 0/5] bonding: setup all queues of slave devices
From: Thomas Monjalon @ 2016-12-21 17:48 UTC (permalink / raw)
To: Jan Blunck
Cc: dev, ferruh.yigit, i.maximets, bruce.richardson, declan.doherty,
ehkinzie, bernard.iremonger, stable
In-Reply-To: <1479986809-14934-1-git-send-email-jblunck@infradead.org>
2016-11-24 12:26, Jan Blunck:
> Prior to 16.11 some drivers (e.g. virtio) still had problems if their
> queues where setup repeatedly. The bonding driver was working around the
> problem by reusing already setup queues. This series of patches changes the
> way how queue setup is done to give control to the driver to properly release
> already initialized queues before they are setup again. Therefore the driver
> call sequence is as if the number of queues is temporarily reduced before the
> queues are setup again.
>
> Ilya Maximets (1):
> Revert "bonding: use existing enslaved device queues"
>
> Jan Blunck (4):
> ethdev: Call rx/tx_queue_release before rx/tx_queue_setup
> ethdev: Free rx/tx_queues after releasing all queues
> ethdev: Add DPDK internal _rte_eth_dev_reset()
> net/bonding: Force reconfiguration of removed slave interfaces
Applied, thanks
^ permalink raw reply
* Re: [PATCH v6] vhost: allow for many vhost user ports
From: Stephen Hemminger @ 2016-12-21 18:06 UTC (permalink / raw)
To: Yuanhan Liu; +Cc: dev, Patrik Andersson, Jan Wickbom
In-Reply-To: <1482313513-1709-1-git-send-email-yuanhan.liu@linux.intel.com>
On Wed, 21 Dec 2016 17:45:13 +0800
Yuanhan Liu <yuanhan.liu@linux.intel.com> wrote:
> From: Jan Wickbom <jan.wickbom@ericsson.com>
>
> Currently select() is used to monitor file descriptors for vhostuser
> ports. This limits the number of ports possible to create since the
> fd number is used as index in the fd_set and we have seen fds > 1023.
> This patch changes select() to poll(). This way we can keep an
> packed (pollfd) array for the fds, e.g. as many fds as the size of
> the array.
>
> Also see:
> http://dpdk.org/ml/archives/dev/2016-April/037024.html
>
> Reported-by: Patrik Andersson <patrik.r.andersson@ericsson.com>
> Signed-off-by: Jan Wickbom <jan.wickbom@ericsson.com>
> Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Why not epoll()? It scales much better. The old System V poll
is just as bad with 1023 fd's.
^ permalink raw reply
* Re: [PATCHv2 03/34] doc: add dpaa2 nic details
From: Mcnamara, John @ 2016-12-21 18:45 UTC (permalink / raw)
To: Hemant Agrawal, dev@dpdk.org
Cc: thomas.monjalon@6wind.com, Richardson, Bruce,
shreyansh.jain@nxp.com, Yigit, Ferruh,
jerin.jacob@caviumnetworks.com
In-Reply-To: <1482180853-18823-4-git-send-email-hemant.agrawal@nxp.com>
> -----Original Message-----
> From: Hemant Agrawal [mailto:hemant.agrawal@nxp.com]
> Sent: Monday, December 19, 2016 8:54 PM
> To: dev@dpdk.org
> Cc: thomas.monjalon@6wind.com; Richardson, Bruce
> <bruce.richardson@intel.com>; shreyansh.jain@nxp.com; Mcnamara, John
> <john.mcnamara@intel.com>; Yigit, Ferruh <ferruh.yigit@intel.com>;
> jerin.jacob@caviumnetworks.com; Hemant Agrawal <hemant.agrawal@nxp.com>
> Subject: [PATCHv2 03/34] doc: add dpaa2 nic details
>
> This patch adds the NXP dpaa2 architecture and pmd details in the Network
> interfaces section.
>
>
> ...
>
> +
> +
> +Running testpmd
> +~~~~~~~~~~~~~~~
> +
> +This section demonstrates how to launch ``testpmd`` with DPAA2 device
> +managed by ``librte_pmd_dpaa2`` in the Linux operating system.
> +
> +#. Configure the resource container,
> +
> +Configure resources in MC and create the DPRC container
> +
> + .. code-block:: console
> +
> + export the DPRC container
> + e.g. export DPRCT=dprc.2
> +
> +#. Start ``testpmd`` with basic parameters:
> +
> + .. code-block:: console
> +
> + ./arm64-dpaa2-linuxapp-gcc/testpmd -c 0xff -n 1 \
> + -- -i --portmask=0x3 --nb-cores=1 --no-flush-rx
> +
> + Example output:
> +
> + .. code-block:: console
> +
> + ...
> +
> + EAL: Registered [pci] bus.
> + EAL: Registered [fslmc] bus.
> + EAL: Detected 8 lcore(s)
> + EAL: Probing VFIO support...
> + EAL: VFIO support initialized
> + .....
> + PMD: DPAA2: Processing Container = dprc.2
> + EAL: fslmc: DPRC contains = 51 devices
> + EAL: fslmc: Bus scan completed
> + .....
> + Configuring Port 0 (socket 0)
> + Port 0: 00:00:00:00:00:01
> + Configuring Port 1 (socket 0)
> + Port 1: 00:00:00:00:00:02
> + ....
> + Checking link statuses...
> + Port 0 Link Up - speed 10000 Mbps - full-duplex
> + Port 1 Link Up - speed 10000 Mbps - full-duplex
> + Done
> + testpmd>
> +
The indentation of the RST elements is slightly wrong here resulting in the output
Html looking a bit odd. The following is probably closer to what is intended:
Running testpmd
~~~~~~~~~~~~~~~
This section demonstrates how to launch ``testpmd`` with DPAA2 device
managed by ``librte_pmd_dpaa2`` in the Linux operating system.
#. Configure the resource container,
Configure resources in MC and create the DPRC container
.. code-block:: console
export the DPRC container
e.g. export DPRCT=dprc.2
#. Start ``testpmd`` with basic parameters:
.. code-block:: console
./arm64-dpaa2-linuxapp-gcc/testpmd -c 0xff -n 1 \
-- -i --portmask=0x3 --nb-cores=1 --no-flush-rx
Example output:
.. code-block:: console
...
EAL: Registered [pci] bus.
EAL: Registered [fslmc] bus.
EAL: Detected 8 lcore(s)
EAL: Probing VFIO support...
EAL: VFIO support initialized
.....
PMD: DPAA2: Processing Container = dprc.2
EAL: fslmc: DPRC contains = 51 devices
EAL: fslmc: Bus scan completed
.....
Configuring Port 0 (socket 0)
Port 0: 00:00:00:00:00:01
Configuring Port 1 (socket 0)
Port 1: 00:00:00:00:00:02
....
Checking link statuses...
Port 0 Link Up - speed 10000 Mbps - full-duplex
Port 1 Link Up - speed 10000 Mbps - full-duplex
Done
testpmd>
^ permalink raw reply
* Re: [PATCH v4 10/23] virtio: Add vtpci_intr_handle() helper to get rte_intr_handle
From: Stephen Hemminger @ 2016-12-21 20:08 UTC (permalink / raw)
To: Jan Blunck; +Cc: dev, shreyansh.jain, david.marchand
In-Reply-To: <1482332986-7599-11-git-send-email-jblunck@infradead.org>
On Wed, 21 Dec 2016 16:09:33 +0100
Jan Blunck <jblunck@infradead.org> wrote:
> 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>
> ---
> drivers/net/virtio/virtio_ethdev.c | 12 +++++++-----
> drivers/net/virtio/virtio_pci.h | 6 ++++++
> 2 files changed, 13 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/virtio/virtio_ethdev.c b/drivers/net/virtio/virtio_ethdev.c
> index 741688e..da9668e 100644
> --- a/drivers/net/virtio/virtio_ethdev.c
> +++ b/drivers/net/virtio/virtio_ethdev.c
> @@ -1162,7 +1162,7 @@ virtio_interrupt_handler(__rte_unused struct rte_intr_handle *handle,
> isr = vtpci_isr(hw);
> PMD_DRV_LOG(INFO, "interrupt status = %#x", isr);
>
> - if (rte_intr_enable(&dev->pci_dev->intr_handle) < 0)
> + if (rte_intr_enable(vtpci_intr_handle(hw)) < 0)
> PMD_DRV_LOG(ERR, "interrupt enable failed");
>
> if (isr & VIRTIO_PCI_ISR_CONFIG) {
Since intr_handle is already an argument to interrupt handler, why not use it?
That is what I did in the Intel driver changes.
^ permalink raw reply
* Re: [PATCH v4 21/23] ethdev: Move filling of rte_eth_dev_info->pci_dev to dev_infos_get()
From: Stephen Hemminger @ 2016-12-21 20:09 UTC (permalink / raw)
To: Jan Blunck; +Cc: dev, shreyansh.jain, david.marchand
In-Reply-To: <1482332986-7599-22-git-send-email-jblunck@infradead.org>
On Wed, 21 Dec 2016 16:09:44 +0100
Jan Blunck <jblunck@infradead.org> wrote:
> Only the device itself can decide its PCI or not.
>
> Signed-off-by: Jan Blunck <jblunck@infradead.org>
> Acked-by: Shreyansh Jain <shreyansh.jain@nxp.com>
> ---
I would still like to kill dev_pci from the dev_info API.
^ permalink raw reply
* [PATCH v2] enablement of avx512 instruction support in aesni_mb_pmd
From: Declan Doherty @ 2016-12-21 22:04 UTC (permalink / raw)
To: dev; +Cc: Declan Doherty
In-Reply-To: <1480671985-3677-1-git-send-email-declan.doherty@intel.com>
In patchset "AESNI MB PMD updates"
(http://dpdk.org/ml/archives/dev/2016-December/050976.html) the AESNI
Multi-Buffer Crypto for IPsec library which the aesni_mb_pmd depends on is
updated to v0.44
This patch enables support for runtime selection of the AVX512 accelerated
functions added to the new version of the Multi-Buffer Crypto for IPsec
library to the aesni_mb_pmd.
V2:
remove the second patch in the original patchset which allowed user to
override the selection of SIMD functions as this was mainly a debug
and test function
Declan Doherty (1):
crypto/aesni_mb: enablement of avx512 support in IPsec_mb library
drivers/crypto/aesni_mb/aesni_mb_ops.h | 28 +++++++++++++++++++++++++++-
drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c | 7 ++++++-
lib/librte_cryptodev/rte_cryptodev.h | 2 ++
3 files changed, 35 insertions(+), 2 deletions(-)
--
2.5.5
^ permalink raw reply
* [PATCH v2] crypto/aesni_mb: enablement of avx512 support in IPsec_mb library
From: Declan Doherty @ 2016-12-21 22:05 UTC (permalink / raw)
To: dev; +Cc: Declan Doherty
In-Reply-To: <1482357900-8382-1-git-send-email-declan.doherty@intel.com>
Release v0.44 of Intel(R) Multi-Buffer Crypto for IPsec library adds
support for AVX512 instructions. This patch enables the new AVX512
accelerated functions from the aesni_mb_pmd crypto poll mode driver.
This patch set requires that the aesni_mb_pmd is linked against the
version 0.44 or greater of the Multi-Buffer Crypto for IPsec library.
Signed-off-by: Declan Doherty <declan.doherty@intel.com>
---
drivers/crypto/aesni_mb/aesni_mb_ops.h | 28 +++++++++++++++++++++++++++-
drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c | 7 ++++++-
lib/librte_cryptodev/rte_cryptodev.h | 2 ++
3 files changed, 35 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/aesni_mb/aesni_mb_ops.h b/drivers/crypto/aesni_mb/aesni_mb_ops.h
index 0c119bf..2d41d73 100644
--- a/drivers/crypto/aesni_mb/aesni_mb_ops.h
+++ b/drivers/crypto/aesni_mb/aesni_mb_ops.h
@@ -44,7 +44,8 @@ enum aesni_mb_vector_mode {
RTE_AESNI_MB_NOT_SUPPORTED = 0,
RTE_AESNI_MB_SSE,
RTE_AESNI_MB_AVX,
- RTE_AESNI_MB_AVX2
+ RTE_AESNI_MB_AVX2,
+ RTE_AESNI_MB_AVX512
};
typedef void (*md5_one_block_t)(void *data, void *digest);
@@ -203,6 +204,31 @@ static const struct aesni_mb_ops job_ops[] = {
aes_xcbc_expand_key_avx2
}
}
+ },
+ [RTE_AESNI_MB_AVX512] = {
+ .job = {
+ init_mb_mgr_avx512,
+ get_next_job_avx512,
+ submit_job_avx512,
+ get_completed_job_avx512,
+ flush_job_avx512
+ },
+ .aux = {
+ .one_block = {
+ md5_one_block_avx512,
+ sha1_one_block_avx512,
+ sha224_one_block_avx512,
+ sha256_one_block_avx512,
+ sha384_one_block_avx512,
+ sha512_one_block_avx512
+ },
+ .keyexp = {
+ aes_keyexp_128_avx512,
+ aes_keyexp_192_avx512,
+ aes_keyexp_256_avx512,
+ aes_xcbc_expand_key_avx512
+ }
+ }
}
};
diff --git a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
index f07cd07..c400b17 100644
--- a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
+++ b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
@@ -613,7 +613,9 @@ cryptodev_aesni_mb_create(const char *name,
}
/* Check CPU for supported vector instruction set */
- if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_AVX2))
+ if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_AVX512F))
+ vector_mode = RTE_AESNI_MB_AVX512;
+ else if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_AVX2))
vector_mode = RTE_AESNI_MB_AVX2;
else if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_AVX))
vector_mode = RTE_AESNI_MB_AVX;
@@ -660,6 +662,9 @@ cryptodev_aesni_mb_create(const char *name,
case RTE_AESNI_MB_AVX2:
dev->feature_flags |= RTE_CRYPTODEV_FF_CPU_AVX2;
break;
+ case RTE_AESNI_MB_AVX512:
+ dev->feature_flags |= RTE_CRYPTODEV_FF_CPU_AVX512;
+ break;
default:
break;
}
diff --git a/lib/librte_cryptodev/rte_cryptodev.h b/lib/librte_cryptodev/rte_cryptodev.h
index 8f63e8f..29d8eec 100644
--- a/lib/librte_cryptodev/rte_cryptodev.h
+++ b/lib/librte_cryptodev/rte_cryptodev.h
@@ -225,6 +225,8 @@ struct rte_cryptodev_capabilities {
/**< Utilises CPU AES-NI instructions */
#define RTE_CRYPTODEV_FF_HW_ACCELERATED (1ULL << 7)
/**< Operations are off-loaded to an external hardware accelerator */
+#define RTE_CRYPTODEV_FF_CPU_AVX512 (1ULL << 8)
+/**< Utilises CPU SIMD AVX512 instructions */
/**
--
2.5.5
^ permalink raw reply related
* Re: [PATCH 0/3] Add DES capability to Intel QuickAssist Technology driver
From: De Lara Guarch, Pablo @ 2016-12-21 23:02 UTC (permalink / raw)
To: Trahe, Fiona, Kusztal, ArkadiuszX, dev@dpdk.org
Cc: Griffin, John, Jain, Deepak K
In-Reply-To: <348A99DA5F5B7549AA880327E580B4358914EF95@IRSMSX101.ger.corp.intel.com>
> -----Original Message-----
> From: Trahe, Fiona
> Sent: Wednesday, December 21, 2016 11:48 AM
> To: Kusztal, ArkadiuszX; dev@dpdk.org
> Cc: De Lara Guarch, Pablo; Griffin, John; Jain, Deepak K
> Subject: RE: [PATCH 0/3] Add DES capability to Intel QuickAssist Technology
> driver
>
>
>
> > -----Original Message-----
> > From: Kusztal, ArkadiuszX
> > Sent: Friday, December 2, 2016 2:16 PM
> > To: dev@dpdk.org
> > Cc: Trahe, Fiona <fiona.trahe@intel.com>; De Lara Guarch, Pablo
> > <pablo.de.lara.guarch@intel.com>; Griffin, John <john.griffin@intel.com>;
> > Jain, Deepak K <deepak.k.jain@intel.com>; Kusztal, ArkadiuszX
> > <arkadiuszx.kusztal@intel.com>
> > Subject: [PATCH 0/3] Add DES capability to Intel QuickAssist Technology
> driver
> >
> > This patchset adds Data Encryption Standard (DES) capability to Intel
> > QuickAssist
> > Technology driver and corresponding tests to test files.
> >
> > Arek Kusztal (3):
> > lib/librte_cryptodev: add DES CBC cipher algorithm
> > crypto/qat: add DES capability to Intel QAT driver
> > app/test: add DES tests to Intel QAT crypto test suite
> >
> > app/test/test_cryptodev.c | 18 ++++
> > app/test/test_cryptodev_blockcipher.c | 5 ++
> > app/test/test_cryptodev_blockcipher.h | 3 +-
> > app/test/test_cryptodev_des_test_vectors.h | 110
> > +++++++++++++++++++++++
> > doc/guides/cryptodevs/qat.rst | 1 +
> > doc/guides/rel_notes/release_17_02.rst | 6 ++
> > drivers/crypto/qat/qat_adf/qat_algs.h | 1 +
> > drivers/crypto/qat/qat_adf/qat_algs_build_desc.c | 16 ++++
> > drivers/crypto/qat/qat_crypto.c | 29 +++++-
> > lib/librte_cryptodev/rte_crypto_sym.h | 4 +
> > 10 files changed, 191 insertions(+), 2 deletions(-)
> >
> > --
> > 2.1.0
> Acked-by: Fiona Trahe <fiona.trahe@intel.com>
Applied to dpdk-next-crypto.
Thanks,
Pablo
^ permalink raw reply
* Re: [PATCH v3 02/12] eal/bus: introduce bus abstraction
From: Stephen Hemminger @ 2016-12-21 23:33 UTC (permalink / raw)
To: Jan Blunck
Cc: Shreyansh Jain, dev, David Marchand, Thomas Monjalon,
Ferruh Yigit, jianbo.liu
In-Reply-To: <CALe+Z01wLK0jYa3ys4v-krRP+oWLKFAwwcgvuyGuS6PnXXTJWQ@mail.gmail.com>
On Wed, 21 Dec 2016 16:38:42 +0100
Jan Blunck <jblunck@infradead.org> wrote:
> On Tue, Dec 20, 2016 at 6:11 PM, Stephen Hemminger
> <stephen@networkplumber.org> wrote:
> > On Tue, 20 Dec 2016 14:17:14 +0100
> > Jan Blunck <jblunck@infradead.org> wrote:
> >
> >> On Fri, Dec 16, 2016 at 2:10 PM, Shreyansh Jain <shreyansh.jain@nxp.com> wrote:
> >> > This patch introduces the rte_bus abstraction for devices and drivers in
> >> > EAL framework. The model is:
> >> > - One or more buses are connected to a CPU (or core)
> >> > - One or more devices are conneted to a Bus
> >> > - Drivers are running instances which manage one or more devices
> >> > - Bus is responsible for identifying devices (and interrupt propogation)
> >> > - Driver is responsible for initializing the device
> >> >
> >> > This patch adds a 'rte_bus' class which rte_driver and rte_device refer.
> >> > This way, each device (rte_xxx_device) would have reference to the bus
> >> > it is based on. As well as, each driver (rte_xxx_driver) would have link
> >> > to the bus and devices on it for servicing.
> >> >
> >> > __ rte_bus_list
> >> > /
> >> > +----------'---+
> >> > |rte_bus |
> >> > | driver_list------> List of rte_bus specific
> >> > | device_list---- devices
> >> > | | `-> List of rte_bus associated
> >> > | | drivers
> >> > +--|------|----+
> >> > _________/ \_________
> >> > +--------/----+ +-\---------------+
> >> > |rte_device | |rte_driver |
> >> > | rte_bus | | rte_bus |
> >> > | rte_driver | | ... |
> >> > | ... | +---------...-----+
> >> > | | |||
> >> > +---||--------+ |||
> >> > || |||
> >> > | \ \\\
> >> > | \_____________ \\\
> >> > | \ |||
> >> > +------|---------+ +----|----------+ |||
> >> > |rte_pci_device | |rte_xxx_device | |||
> >> > | .... | | .... | |||
> >> > +----------------+ +---------------+ / | \
> >> > / | \
> >> > _____________________/ / \
> >> > / ___/ \
> >> > +-------------'--+ +------------'---+ +--'------------+
> >> > |rte_pci_driver | |rte_vdev_driver | |rte_xxx_driver |
> >> > | .... | | .... | | .... |
> >> > +----------------+ +----------------+ +---------------+
> >> >
> >> > This patch only enables the bus references on rte_driver and rte_driver.
> >> > EAL wide global device and driver list continue to exist until an instance
> >> > of bus is added in subsequent patches.
> >> >
> >> > This patch also introduces RTE_REGISTER_BUS macro on the lines of
> >> > RTE_PMD_REGISTER_XXX. Key difference is that the constructor priority has
> >> > been explicitly set to 101 so as to execute bus registration before PMD.
> >> >
> >> > Signed-off-by: Shreyansh Jain <shreyansh.jain@nxp.com>
> >> >
> >
> > Ok, but let's keep this as bus type not bus. It gets really hard and complex
> > to enumerate all layers of PCI bus and bridges.
>
> As far as I understand it this isn't the intention to replicate the
> hierarchy of buses we have in the kernel. The PCI bus in this case
> becomes a list of PCI devices.
One of the motivations seems to be "lets be able to handle lots of devices",
but the current model with an array of ports is not going to scale well for that.
It is time to make rte_eth_devices into rb-tree and get rid of MAX_PORTS config
option.
^ permalink raw reply
* Re: [PATCH 2/2] net/ixgbe: calculate correct number of received packets for ARM NEON-version vPMD
From: Jianbo Liu @ 2016-12-22 1:05 UTC (permalink / raw)
To: Jerin Jacob; +Cc: dev, Zhang, Helin, Ananyev, Konstantin
In-Reply-To: <20161221100848.GA4506@localhost.localdomain>
Hi Jerin,
On 21 December 2016 at 18:08, Jerin Jacob
<jerin.jacob@caviumnetworks.com> wrote:
> On Mon, Dec 19, 2016 at 11:39:18AM +0530, Jianbo Liu wrote:
>
> Hi Jianbo,
>
>> vPMD will check 4 descriptors in one time, but the statuses are not consistent
>> because the memory allocated for RX descriptors is cacheable huagepage.
> Is it different in X86 case ?i.e Is x86 creating non cacheable hugepages?
> I am just looking at what it takes to fix similar issues for all drivers wrt armv8.
>
> Are you able to reproduce this issue any armv8 platform. If so, could
> you please the platform detail and commands to reproduce this issue?
>
I have tested on Huawei D03 and Softiron with Intel X540, same issue
for both of them.
The setup is very simple: loopback 2 ports, then run testpmd.
^ permalink raw reply
* Re: [PATCH 2/2] net/ixgbe: calculate correct number of received packets for ARM NEON-version vPMD
From: Jianbo Liu @ 2016-12-22 1:18 UTC (permalink / raw)
To: Bruce Richardson; +Cc: Jerin Jacob, dev, Zhang, Helin, Ananyev, Konstantin
In-Reply-To: <20161221110331.GA9108@bricha3-MOBL3.ger.corp.intel.com>
On 21 December 2016 at 19:03, Bruce Richardson
<bruce.richardson@intel.com> wrote:
> On Wed, Dec 21, 2016 at 03:38:51PM +0530, Jerin Jacob wrote:
>> On Mon, Dec 19, 2016 at 11:39:18AM +0530, Jianbo Liu wrote:
>>
>> Hi Jianbo,
>>
>> > vPMD will check 4 descriptors in one time, but the statuses are not consistent
>> > because the memory allocated for RX descriptors is cacheable huagepage.
>> Is it different in X86 case ?i.e Is x86 creating non cacheable hugepages?
>
> This is not a problem on IA, because the instruction ordering rules on
> IA guarantee that the reads will be done in the correct program order,
> and we never get stale cache data.
>
Yes, I think it's an issue for ARM arch.
It's because more than one cacheline-sized data (4/8 descriptors can
be in two cachelines) will be read at one time in bulk alloc RX or
vPMD.
There is the same issue for i40e, I'll send the same patch later.
^ permalink raw reply
* Example(Load_balancer) Tx Flush Bug(This bug dpdk each version)
From: Maple @ 2016-12-22 2:05 UTC (permalink / raw)
To: dev; +Cc: maintainers, 李非, 施展
In-Reply-To: <2016122122394164225248@raisecom.com>
From: Maple <liujian@raisecom.com>
To: <dev@dpdk.org>
Cc: <thomas.monjalon@6wind.com>, <lifei@raisecom.com>, <shizhan@raisecom.com>
Subject: [PATCH] Load_balancer Tx Flush Bug
Date: Thu, 22 Dec 2016 09:57:48 +0800
Message-Id: <1482371868-19669-1-git-send-email-liujian@raisecom.com>
X-Mailer: git-send-email 1.9.1
In-Reply-To: <2016122122394164225248@raisecom.com>
References: <2016122122394164225248@raisecom.com>
We found a bug in use load_balancer example,and,This bug DPDK each version.
In IO tx flush, only flush port 0.
So,If I enable more than the Port,then,In addition to 0 port won't flush.
Signed-off-by: Maple <liujian@raisecom.com>
---
a/examples/load_balancer/runtime.c | 667 ++++++++++++++++++++++++++++++++++++
b/examples/load_balancer/runtime.c | 669 +++++++++++++++++++++++++++++++++++++
2 files changed, 1336 insertions(+)
create mode 100644 a/examples/load_balancer/runtime.c
create mode 100644 b/examples/load_balancer/runtime.c
diff --git a/examples/load_balancer/runtime.c b/examples/load_balancer/runtime.c
index 9612392..3a2e900 100644
--- a/test/a/examples/load_balancer/runtime.c
+++ b/test/b/examples/load_balancer/runtime.c
@@ -418,9 +418,11 @@ app_lcore_io_tx(
static inline void
app_lcore_io_tx_flush(struct app_lcore_params_io *lp)
{
+ uint8_t i;
uint8_t port;
- for (port = 0; port < lp->tx.n_nic_ports; port ++) {
+ port = lp->tx.nic_ports[0];
+ for (i = 0; i < lp->tx.n_nic_ports; i ++) {
uint32_t n_pkts;
if (likely((lp->tx.mbuf_out_flush[port] == 0) ||
^ permalink raw reply related
* Re: [PATCH v2 00/30] update ixgbe shared code to version 16.11.21
From: Dai, Wei @ 2016-12-22 2:35 UTC (permalink / raw)
To: Yigit, Ferruh, dev@dpdk.org; +Cc: Zhang, Helin, Ananyev, Konstantin
In-Reply-To: <6e5d4c65-f0ee-4b18-4935-fa9fce7c84d6@intel.com>
Many thanks to you for your taking time to review this patch set.
Thanks
-Wei
> -----Original Message-----
> From: Yigit, Ferruh
> Sent: Thursday, December 22, 2016 1:20 AM
> To: Dai, Wei <wei.dai@intel.com>; dev@dpdk.org
> Cc: Zhang, Helin <helin.zhang@intel.com>; Ananyev, Konstantin
> <konstantin.ananyev@intel.com>
> Subject: Re: [dpdk-dev] [PATCH v2 00/30] update ixgbe shared code to version
> 16.11.21
>
> On 12/21/2016 9:47 AM, Wei Dai wrote:
> > update ixgbe shared code to version 16.11.21 .
> > v2 changes:
> > modify subject line and message body of git log according to
> > feedbacks from communtiy.
> >
> > split the 24th patch into 2 separate ones.
> > the 24th of v1 is net/ixgbe/base: add EEE support for DNL-controlled PHYs
> > the 24th of v2 is net/ixgbe/base: add EEE support for some PHYs
> > the 25th of v2 is net/ixgbe/base: remove unused enum type
> >
> > correct RAEDME
> >
> > Wei Dai (30):
> > net/ixgbe/base: fix PHY reset check for x550em-ext
> > net/ixgbe/base: fix clearing SAN MAC address
> > net/ixgbe/base: use fast MDIO for non-10G devices
> > net/ixgbe/base: fix PHY identification for x550a
> > net/ixgbe/base: clean up X557 link status check
> > net/ixgbe/base: add driver version to firmware
> > net/ixgbe/base: store link active LED
> > net/ixgbe/base: cleanup X540 checksum calculation
> > net/ixgbe/base: enable LASI only for X552 devices
> > net/ixgbe/base: limit iXFI setup to X552 devices
> > net/ixgbe/base: fix getting PHY type for some x550 devices
> > net/ixgbe/base: fix SGMII link setup for M88 PHYs
> > net/ixgbe/base: cleanup dead EEE code
> > net/ixgbe/base: fix setting unsupported autoneg speeds
> > net/ixgbe/base: support FW commands to control some PHYs
> > net/ixgbe/base: use FW commands to control some PHYs
> > net/ixgbe/base: support busy SGMII register reads
> > net/ixgbe/base: include new speeds in VFLINK interpretation
> > net/ixgbe/base: limit 5Gb support to X550 devices
> > net/ixgbe/base: add physical layer options for FW PHY type
> > net/ixgbe/base: remove unneeded MAC type check
> > net/ixgbe/base: remove unused PHY ID
> > net/ixgbe/base: update FW PHY flow control
> > net/ixgbe/base: add EEE support for some PHYs
> > net/ixgbe/base: remove unused enum type
> > net/ixgbe/base: fix IXGBE LSWFW register
> > net/ixgbe/base: remove unused EEE code
> > net/ixgbe/base: add write flush required by Inphi PHY
> > net/ixgbe/base: report physical layer for SGMII PHY type
> > net/ixgbe/base: update shared code version to 2016.11.21
> <...>
>
> Series applied to dpdk-next-net/master, thanks.
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox