[dpdk-dev] Getting started - sanity check
Thanks for the note! I'll take another look at it.
Cheers,
Gilbert
From: Wiles, Keith
Sent: Saturday, May 9, 2015 12:41 PM
To: Clark, Gilbert
Cc: dev at dpdk.org
Subject: Re: [dpdk-dev] Getting started - sanity check
Sent from my iPhone
> On May 9, 2015, at 9:27 AM, Clark, Gilbert wrote:
>
>
> Hi folks:
>
> I'm brand new to DPDK. Read about it off and on occasionally, but never had
> the chance to sit down and play with things until now. It's been fun so far:
> just been working on a few toy applications to get myself started.
>
> I have run into a question, though: when calling rte_eth_tx_burst with a
> ring-backed PMD I've set up, the mbufs I've sent never seem to be freed.
> This seems to make some degree of sense, but ... since I'm new, and because
> the documentation says rte_eth_tx_burst should eventually free mbufs that are
> sent [1], I wanted to make sure I'm on track and not just misunderstanding
> the way something works [2].
The mbufs are free as needed or when a watermark is hit in the driver. One
other thing I found is you need to send enough packets to hit the water mark
for the tx mbufs start to get freed. Also you have to have enough mbufs
allocated to hit these watermarks. I just pick two times the ring size just to
be safe.
Hope that helps.
>
> Thanks,
> Gilbert Clark
>
> [1] From http://dpdk.org/doc/api/rte__ethdev_8h.html :
>
> It is the responsibility of the rte_eth_tx_burst() function to transparently
> free the memory buffers of packets previously sent
>
> [2] From lib/librte_pmd_ring.c:
>
> static uint16_t
> eth_ring_tx(void *q, struct rte_mbuf **bufs, uint16_t nb_bufs)
> {
>void **ptrs = (void *)&bufs[0];
>struct ring_queue *r = q;
>const uint16_t nb_tx = (uint16_t)rte_ring_enqueue_burst(r->rng,
>ptrs, nb_bufs);
>if (r->rng->flags & RING_F_SP_ENQ) {
>r->tx_pkts.cnt += nb_tx;
>r->err_pkts.cnt += nb_bufs - nb_tx;
>} else {
>rte_atomic64_add(&(r->tx_pkts), nb_tx);
>rte_atomic64_add(&(r->err_pkts), nb_bufs - nb_tx);
>}
>return nb_tx;
> }
>
> This doesn't ever appear to free a transmitted mbuf ... unless there's code
> to do that somewhere else that I'm missing?
[dpdk-dev] [PATCH] kni: fix igb and ixgbe kni ethtool get_link op
Hi Helin,
No matter the cable is plugged or not, the return value of link detected
is yes when I run ethtool on a kni interface.
But the return values of speed and duplex are correct. So I just copy
the link detected codes of get_settings op.
On 05/04/2015 04:55 PM, Zhang, Helin wrote:
> Hi Chia
>
>> -Original Message-
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Shelton Chia
>> Sent: Friday, April 3, 2015 11:19 PM
>> To: dev at dpdk.org
>> Subject: [dpdk-dev] [PATCH] kni: fix igb and ixgbe kni ethtool get_link op
>>
>> igb and ixgbe's link detected always return yes, fix get_link func refer to
>> get_settings, it works correctly for my i350 and 82599es nic.
> Could you help to add more detailed description of why we need these code
> changes? Thanks!
>> Signed-off-by: Shelton Chia
>> ---
>> .../linuxapp/kni/ethtool/igb/igb_ethtool.c | 18 ++-
>> .../linuxapp/kni/ethtool/ixgbe/ixgbe_ethtool.c | 26
>> +-
>> 2 files changed, 32 insertions(+), 12 deletions(-)
>>
>> diff --git a/lib/librte_eal/linuxapp/kni/ethtool/igb/igb_ethtool.c
>> b/lib/librte_eal/linuxapp/kni/ethtool/igb/igb_ethtool.c
>> index f3c48b2..5457f48 100644
>> --- a/lib/librte_eal/linuxapp/kni/ethtool/igb/igb_ethtool.c
>> +++ b/lib/librte_eal/linuxapp/kni/ethtool/igb/igb_ethtool.c
>> @@ -383,19 +383,15 @@ static int igb_set_settings(struct net_device
>> *netdev, struct ethtool_cmd *ecmd) static u32 igb_get_link(struct
>> net_device *netdev) {
>> struct igb_adapter *adapter = netdev_priv(netdev);
>> -struct e1000_mac_info *mac = &adapter->hw.mac;
>> +struct e1000_hw *hw = &adapter->hw;
>> +u32 status;
>>
>> -/*
>> - * If the link is not reported up to netdev, interrupts are disabled,
>> - * and so the physical link state may have changed since we last
>> - * looked. Set get_link_status to make sure that the true link
>> - * state is interrogated, rather than pulling a cached and possibly
>> - * stale link state from the driver.
>> - */
>> -if (!netif_carrier_ok(netdev))
>> -mac->get_link_status = 1;
>> +status = E1000_READ_REG(hw, E1000_STATUS);
> Can ' check_for_link ' be used for checking the link here? It needs to support
> all possible link types.
>
>> -return igb_has_link(adapter);
>> +if (status & E1000_STATUS_LU)
>> +return 1;
>> +else
>> +return 0;
>> }
>>
>> static void igb_get_pauseparam(struct net_device *netdev, diff --git
>> a/lib/librte_eal/linuxapp/kni/ethtool/ixgbe/ixgbe_ethtool.c
>> b/lib/librte_eal/linuxapp/kni/ethtool/ixgbe/ixgbe_ethtool.c
>> index 11472bd..184b14f 100644
>> --- a/lib/librte_eal/linuxapp/kni/ethtool/ixgbe/ixgbe_ethtool.c
>> +++ b/lib/librte_eal/linuxapp/kni/ethtool/ixgbe/ixgbe_ethtool.c
>> @@ -801,6 +801,30 @@ static void ixgbe_get_regs(struct net_device *netdev,
>> struct ethtool_regs *regs,
>> regs_buff[1128] = IXGBE_READ_REG(hw, IXGBE_MFLCN); }
>>
>> +static u32 ixgbe_get_link(struct net_device *netdev) {
>> +struct ixgbe_adapter *adapter = netdev_priv(netdev);
>> +struct ixgbe_hw *hw = &adapter->hw;
>> +u32 link_speed = 0;
>> +bool link_up;
>> +
>> +if (!in_interrupt()) {
>> +hw->mac.ops.check_link(hw, &link_speed, &link_up, false);
> As done in kernel driver function ' ixgbe_watchdog_update_link ()', more
> checks
> may be needed.
>
> Regards,
> Helin
>
>> +} else {
>> +/*
>> + * this case is a special workaround for RHEL5 bonding
>> + * that calls this routine from interrupt context
>> + */
>> +link_speed = adapter->link_speed;
>> +link_up = adapter->link_up;
>> +}
>> +
>> +if (link_up)
>> +return 1;
>> +else
>> +return 0;
>> +}
>> +
>> static int ixgbe_get_eeprom_len(struct net_device *netdev) {
>> struct ixgbe_adapter *adapter = netdev_priv(netdev); @@ -2838,7
>> +2862,7 @@ struct ethtool_ops ixgbe_ethtool_ops = {
>> .get_wol= ixgbe_get_wol,
>> .set_wol= ixgbe_set_wol,
>> .nway_reset = ixgbe_nway_reset,
>> -.get_link = ethtool_op_get_link,
>> +.get_link = ixgbe_get_link,
>> .get_eeprom_len = ixgbe_get_eeprom_len,
>> .get_eeprom = ixgbe_get_eeprom,
>> .set_eeprom = ixgbe_set_eeprom,
>> --
>> 2.3.5
--
???
??
[dpdk-dev] Intel fortville not working with multi-segment
Hi, can someone assist regarding this issue? Is it a known limitation in i40e/dpdk (no support for multi-segment)? Thx Nissim -Original Message- From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Nissim Nisimov Sent: Thursday, May 07, 2015 5:44 PM To: 'dev at dpdk.org' Subject: [dpdk-dev] Intel fortville not working with multi-segment Hi, I am trying to work with Intel Fortville (XL710) NICs in Passthrough mode from a VM running dpdk app. First I didn't have any TX traffic from the VM, I got dpdk patch for this issue and it fixed it. (http://www.dpdk.org/dev/patchwork/patch/4588/) But now I see that when trying to run multi-segment traffic not all the packets reaching the VM (I tested it on bare metal as well and saw the same issue) Is it a known issue? any workaround for it? Thanks, Nissim
[dpdk-dev] [PATCH v3] kni: fix compilation issue in KNI vhost on kernel 3.19/4.0
Hi Pablo,
2015-05-05 15:08, Pablo de Lara:
> Due to commit c0371da6 in kernel 3.19, which removed msg_iov
> and msg_iovlen from struct msghdr, DPDK would not build.
> Also, functions memcpy_toiovecend and memcpy_fromiovecend
> were removed in commits ba7438ae and 57dd8a07, being substituted by
> copy_from_iter and copy_to_iter.
>
> This patch makes use of struct iov_iter, which has references
> to msg_iov and msg_iovln, and makes use of copy_from_iter
> and copy_to_iter.
>
> Changes in v2:
> - Replaced functions memcpy_toiovecend and memcpy_fromiovecend
> with copy_from_iter and copy_to_iter
>
> Changes in v3:
> - Fixed variable names
> - Add missing checks
>
> Reported-by: Thomas Monjalon
> Signed-off-by: Pablo de Lara
I have the following errors with Linux 4.0.1:
lib/librte_eal/linuxapp/kni/igb_main.c:2321:2: error: initialization from
incompatible pointer type
.ndo_bridge_setlink = igb_ndo_bridge_setlink,
^
lib/librte_eal/linuxapp/kni/igb_main.c:2321:2: error: (near initialization for
?igb_netdev_ops.ndo_bridge_setlink?)
lib/librte_eal/linuxapp/kni/igb_main.c: In function ?igb_xmit_frame_ring?:
lib/librte_eal/linuxapp/kni/igb_main.c:5482:2: error: implicit declaration of
function ?vlan_tx_tag_present?
if (vlan_tx_tag_present(skb)) {
^
lib/librte_eal/linuxapp/kni/igb_main.c:5484:3: error: implicit declaration of
function ?vlan_tx_tag_get?
tx_flags |= (vlan_tx_tag_get(skb) << IGB_TX_FLAGS_VLAN_SHIFT);
^
[dpdk-dev] [PATCH v3] kni: fix compilation issue in KNI vhost on kernel 3.19/4.0
Hi Thomas,
> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Sunday, May 10, 2015 10:26 PM
> To: De Lara Guarch, Pablo
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v3] kni: fix compilation issue in KNI vhost on
> kernel 3.19/4.0
>
> Hi Pablo,
>
> 2015-05-05 15:08, Pablo de Lara:
> > Due to commit c0371da6 in kernel 3.19, which removed msg_iov
> > and msg_iovlen from struct msghdr, DPDK would not build.
> > Also, functions memcpy_toiovecend and memcpy_fromiovecend
> > were removed in commits ba7438ae and 57dd8a07, being substituted by
> > copy_from_iter and copy_to_iter.
> >
> > This patch makes use of struct iov_iter, which has references
> > to msg_iov and msg_iovln, and makes use of copy_from_iter
> > and copy_to_iter.
> >
> > Changes in v2:
> > - Replaced functions memcpy_toiovecend and memcpy_fromiovecend
> > with copy_from_iter and copy_to_iter
> >
> > Changes in v3:
> > - Fixed variable names
> > - Add missing checks
> >
> > Reported-by: Thomas Monjalon
> > Signed-off-by: Pablo de Lara
>
> I have the following errors with Linux 4.0.1:
>
> lib/librte_eal/linuxapp/kni/igb_main.c:2321:2: error: initialization from
> incompatible pointer type
> .ndo_bridge_setlink = igb_ndo_bridge_setlink,
> ^
> lib/librte_eal/linuxapp/kni/igb_main.c:2321:2: error: (near initialization for
> ?igb_netdev_ops.ndo_bridge_setlink?)
> lib/librte_eal/linuxapp/kni/igb_main.c: In function ?igb_xmit_frame_ring?:
> lib/librte_eal/linuxapp/kni/igb_main.c:5482:2: error: implicit declaration of
> function ?vlan_tx_tag_present?
> if (vlan_tx_tag_present(skb)) {
> ^
> lib/librte_eal/linuxapp/kni/igb_main.c:5484:3: error: implicit declaration of
> function ?vlan_tx_tag_get?
>tx_flags |= (vlan_tx_tag_get(skb) << IGB_TX_FLAGS_VLAN_SHIFT);
>^
I sent a patch for that (kni: fix compilation issue on kernel 4.0.0), by the
end of last month.
Is it OK to merge it or do you want me to send a v4 of this one, including that
fix?
Thanks,
Pablo
