DPDK usage discussions
 help / color / mirror / Atom feed
From: Toby DiPasquale <toby@cbcg.net>
To: Jesper Wramberg <jesper.wramberg@gmail.com>
Cc: users@dpdk.org
Subject: Re: [dpdk-users] pkts not transmitting with DPDK 2.2.0
Date: Sun, 27 Mar 2016 14:17:57 -0400	[thread overview]
Message-ID: <CAML0wpFVYpxAaSDXbuwx_YOg3yzCQ9iPe_As_u_2ziWstXtFEQ@mail.gmail.com> (raw)
In-Reply-To: <CALhSPosDyHn1Sq=pr37JUo-Vxc4tczMBT6TiQ1Ufhb805R+WXg@mail.gmail.com>

Hi Jesper,

Neither ethtool nor ip return for this NIC:

  # ethtool -S eth1
  Cannot get stats strings information: No such device
  # ip link show eth1
  Device "eth1" does not exist.

The NIC has been disconnected from the OS via dpdk_nic_bind.py. The
MAC addresses do match, also. If the NIC is not visible to the OS, and
I'm not turning spoof checking on in the DPDK app, would the setting
while it is attached to the kernel make a difference?


On Sun, Mar 27, 2016 at 4:57 AM, Jesper Wramberg
<jesper.wramberg@gmail.com> wrote:
> Hey Toby,
>
> It seems you are using a VF yes ? I did some testing of SR-IOV a while ago
> on an Intel NIC. I remember having to fiddle with it to get it working, so
> here are a new notes/questions you might find useful (or maybe not :-)).
>
> Are there any errors in the stats on the physical function (ethtool -S
> <linux PF interface>) ?
> Since you are receiving packets the MAC is probably correct. But anyway:
> Did you check the MAC addresses of the VF using "ip link show <linux PF
> interface>" - do they match what DPDK uses ?
> Is spoof checking enabled on the PF ?
>
> My tests were with an XL710 only using Linux (no DPDK). To be able to TX
> from the VF after changing stuff with "ip link set..." I think I may have
> had to reset the VF or PF using "ip link set .. down/up".
>
> I know I'm not exactly providing any answers here - and my memory isn't
> helping - but maybe something can point you in the right direction.
>
> Regards,
> Jesper
>
>
> 2016-03-26 20:24 GMT+01:00 Toby DiPasquale <toby@cbcg.net>:
>>
>> Hi all,
>>
>> I'm having an issue getting packets to actually transmit out of the
>> NIC with DPDK 2.2.0. I've built a simple UDP echo server here:
>> https://github.com/codeslinger/udpecho
>>
>> Packets are received just fine, and they appear to say they are
>> transmitted, as well, but they never actually leave the NIC. Here is
>> some sample output with the details of how I'm running this:
>> https://gist.github.com/codeslinger/d2e59b00bdc1208f4369
>>
>> I'm kinda stumped. I had a local person with DPDK experience look at
>> this code and he was similarly confused as to why it wasn't working.
>> Anyone have any ideas on this one? Thanks in advance!
>>
>> --
>> Toby DiPasquale
>
>



-- 
Toby DiPasquale

  reply	other threads:[~2016-03-27 18:17 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-26 19:24 Toby DiPasquale
2016-03-27  8:57 ` Jesper Wramberg
2016-03-27 18:17   ` Toby DiPasquale [this message]
2016-03-27 20:19     ` Jesper Wramberg
2016-03-28  1:02       ` John Boyle

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAML0wpFVYpxAaSDXbuwx_YOg3yzCQ9iPe_As_u_2ziWstXtFEQ@mail.gmail.com \
    --to=toby@cbcg.net \
    --cc=jesper.wramberg@gmail.com \
    --cc=users@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).