[dpdk-dev] DPDK log system is not working

[Lu, Patrick]

Hi,

I've recently rebased my DPDK code from v16.07 to v17.05-rc1 and learned 
rte_set_log_type() API is deprecated now, so I switched to rte_log_set_level() 
API.

My old code was as follow:

#define C2CV3 RTE_LOGTYPE_USER1
#define D RTE_LOG_DEBUG
#define I RTE_LOG_INFO
#define N RTE_LOG_NOTICE
rte_set_log_type(C2CV3, 1);
rte_log(I, C2CV3, "Hello World\n");

The new code (according to the rte_set_log_type or test_log.c):
rte_log_set_level(C2CV3, 0);
rte_log(I, C2CV3, "Does not work\n");

Also, the test_log.c looks broken too.

Patrick

[dpdk-dev] How to include pre-build object file (.o) in DPDK makefile?

[Lu, Patrick]

-Original Message-
From: Yigit, Ferruh 
Sent: Friday, September 16, 2016 11:05 AM
To: Lu, Patrick ; dev at dpdk.org
Subject: Re: [dpdk-dev] How to include pre-build object file (.o) in DPDK 
makefile?

On 9/16/2016 6:04 PM, Lu, Patrick wrote:
> Hi,
> 
> I'm trying to include some hand written assembly (compiled by yasm) in my 
> DPDK program. I couldn't find any example linking the DPDK C code with 
> pre-compiled .o file. I've searched the mk/ and found OBJS-y seems the right 
> variable to include .o file, but when generating the final executable, OBJS-y 
> contains only main.o (generating from main.c).
> 
> I've tried to put my .o file in both source directory as well as 
> build/
> 

Possible to use EXTRA_LDLIBS to provide the object file name, and put object 
file into build folder.

Following example worked for me:

$ nm foo.o
 T foo

$ cp foo.o examples/skeleton/build/

$ make -C examples/skeleton EXTRA_LDLIBS="foo.o"
make: Entering directory '.../examples/skeleton'
  CC basicfwd.o
  LD basicfwd
  INSTALL-APP basicfwd
  INSTALL-MAP basicfwd.map
make: Leaving directory '.../examples/skeleton'

$ nm examples/skeleton/build/basicfwd | grep foo 0055fd1d T foo

Perfect! This works for me.

Sincerely,

Patrick

[dpdk-dev] How to include pre-build object file (.o) in DPDK makefile?

[Lu, Patrick]

Hi,

I'm trying to include some hand written assembly (compiled by yasm) in my DPDK 
program. I couldn't find any example linking the DPDK C code with pre-compiled 
.o file. I've searched the mk/ and found OBJS-y seems the right variable to 
include .o file, but when generating the final executable, OBJS-y contains only 
main.o (generating from main.c).

I've tried to put my .o file in both source directory as well as build/

Thanks,

Patrick

[dpdk-dev] [PATCH] scripts: enable extended tag of PCIe

[Lu, Patrick]

Hi Helin and Thomas,

Rather than an additional patch. Can we always enable extended tag in i40e 
driver? There is no negative impact for enabling extended tag. (Even on devices 
that don't support extended tag, the PCIe packet will simply ignore the bit and 
go on.)

Best,

Patrick

-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Liu, Yong
Sent: Tuesday, March 24, 2015 8:32 PM
To: Zhang, Helin; Thomas Monjalon
Cc: dev at dpdk.org
Subject: Re: [dpdk-dev] [PATCH] scripts: enable extended tag of PCIe

Hi Helin,
This patch look fine for me. Just need add some descriptions about the extended 
tag. 
If this script work only on FVL device, maybe it should be renamed like 
"set_fvl_extended_tag". 

> -Original Message-
> From: Zhang, Helin
> Sent: Tuesday, March 24, 2015 9:08 AM
> To: Thomas Monjalon; Liu, Yong
> Cc: dev at dpdk.org; Butler, Siobhan A
> Subject: RE: [dpdk-dev] [PATCH] scripts: enable extended tag of PCIe
> 
> Hi Thomas
> 
> Zhida is our intern who has already been back to university. I think 
> Yong might have reviewed it.
> It is good supplementation for setting extended tag on Linux, though 
> not necessary. I am OK to have it merged or not. Thanks!
> 
> Marvin, could you help to ack it, as I know you have reviewed it?
> 
> Regards,
> Helin
> 
> > -Original Message-
> > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> > Sent: Monday, March 23, 2015 7:53 PM
> > To: Zang, Zhida
> > Cc: dev at dpdk.org; Butler, Siobhan A; Zhang, Helin
> > Subject: Re: [dpdk-dev] [PATCH] scripts: enable extended tag of PCIe
> >
> > Hi,
> >
> > This patch needs review and documentation.
> > It's going to be dropped if nobody cares.
> >
> > There were some previous discussions about it:
> > http://dpdk.org/ml/archives/dev/2015-February/012708.html
> >
> >
> > 2015-01-30 12:57, zhida zang:
> > > As 'extended tag' of PCIe needs to be enabled for i40e high 
> > > performance, Linux command of 'setpci' can be used to check and 
> > > set the corresponding bit of 'extended tag' of PCIe configuration space.
> > > The script is to check and set the right bit in PCIe configuration
> space to
> > enable 'extended tag'.
> > >
> > > Signed-off-by: Zhida Zang 
> > > ---
> > >  tools/set_pci.py | 124
> > > +++
> > >  1 file changed, 124 insertions(+)  create mode 100755 
> > > tools/set_pci.py
> > >
> > > diff --git a/tools/set_pci.py b/tools/set_pci.py new file mode 
> > > 100755 index 000..e242efb
> > > --- /dev/null
> > > +++ b/tools/set_pci.py
> > > @@ -0,0 +1,124 @@
> > > +#! /usr/bin/python
> > > +import sys
> > > +import os
> > > +import subprocess
> > > +import getopt
> > > +from os.path import basename
> > > +
> > > +# The register to check if extended tag is supported or not.
> > > +PCI_DEV_CAP_REG = 0xA4
> > > +# The control register which contains the bit to enable/disable
> 'extended
> > tag'.
> > > +PCI_DEV_CTRL_REG = 0xA8
> > > +# The mask of 'extended tag' in capability register.
> > > +PCI_DEV_CAP_EXT_TAG_MASK = 0x20
> > > +# The mask of 'extended tag' in control register.
> > > +PCI_DEV_CTRL_EXT_TAG_MASK = 0x100
> > > +
> > > +dev_ids = {}
> > > +flag = "Set"
> > > +
> > > +
> > > +def usage():
> > > +'''Print usage information for the program'''
> > > +argv0 = basename(sys.argv[0])
> > > +print """
> > > +Usage:
> > > +--
> > > +
> > > +%(argv0)s [options] DEVICE1 DEVICE2 
> > > +
> > > +where DEVICE1, DEVICE2 etc, are specified via PCI 
> > > +"domain:bus:slot.func" syntax or "bus:slot.func" syntax. For 
> > > +devices bound to Linux kernel drivers, they may also be referred 
> > > +to by Linux
> interface
> > name e.g. eth0, eth1, em0, em1, etc.
> > > +
> > > +Options:
> > > +--help, --usage:
> > > +Display usage information and quit
> > > +
> > > +-s --set:
> > > +Set the following pci device
> > > +
> > > +-u --Unset:
> > > +Unset the following pci device
> > > +
> > > +Examples:
> > > +-
> > > +To set pci 0a:00.0
> > > +%(argv0)s -s 0a:00.0
> > > +%(argv0)s --set 0a:00.0
> > > +
> > > +To unset :01:00.0
> > > +%(argv0)s -u :01:00.0
> > > +%(argv0)s --unset :01:00.0
> > > +
> > > +To set :02:00.0 and :02:00.1
> > > +%(argv0)s -s 02:00.0 02:00.1
> > > +
> > > +""" % locals()  # replace items from local variables
> > > +
> > > +
> > > +def parse_args():
> > > +global flag
> > > +global dev_ids
> > > +if len(sys.argv) <= 1:
> > > +usage()
> > > +sys.exit(0)
> > > +try:
> > > +opts, dev_ids = getopt.getopt(
> > > +sys.argv[1:],
> > > +"su",
> > > +["help", "usage", "set", "unset"]
> > > +)
> > > +except getopt.GetoptError, error:
> > > +print str(error)
> > > +print "Run '%s --usage' for further information" % sys.argv[0]
> > > +sys.exit(1)
> > > +

[dpdk-dev] l2fwd application - packets not getting forwarded

[Lu, Patrick]

You can also pass iommu=pt, then you can keep intel_iommu=on and have dpdk 
co-exist on native and virtialized.

Patrick

On Jun 15, 2014 11:08 PM, Raj Ravi  wrote:
I can get this working after some changes.

1. I have pci_assign=buses and intel_iommu=on present in grub.conf ,
Removed them
2. Before running l2fwd application, removed ixgbe driver. I was actually
getting some kernel errors without these steps, while running l2fwd application.

Now, I can see the packets getting forwarded using l2fwd application and able
to observe the packets using tcpdump.

Yes, as you said, ping is not getting reply back. but it is getting forwarded to
the other end ( observed using tcpdump).

Thanks!


On Fri, Jun 13, 2014 at 10:39 PM, Richardson, Bruce
 wrote:
>> -Original Message-
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Raj Ravi
>> Sent: Thursday, June 12, 2014 6:35 PM
>> To: dev at dpdk.org
>> Subject: Re: [dpdk-dev] l2fwd application - packets not getting forwarded
>>
>> Is there any requirement to modify l2fwd appliucation with updated mac
>> address to make it work ?
>>
>> In one example, it is mentioned something similar.
>> www.slideshare.net/hisaki/intel-dpdk-step-by-step-instructions
>>
>>
>> Also, in order to make ping work it is necessary to add static entry
>> for those IP addresses ?
>>
>> Please let me know. Thanks,
>>
> Hi,
>
> In terms of using ping: the Intel DPDK works below the IP level, and the 
> basic l2fwd sample app has no concept of an IP address or what an ICMP ping 
> message is, so you won't get a proper ping reply out of the application as 
> there is no IP stack to reply. What it will do, its take the ping message and 
> forward it out a different port.
>
> As for the more basic question of receiving packets on the NIC, normally, 
> yes, you would need to set the destination mac address of your packets to 
> match that of the NIC port, but in this case I believe the l2fwd app switches 
> the port to promiscuous mode so it should receive all packets sent to it. 
> [Other sample apps often need a "-P" flag passed to them to do this.]
>
> Regards,
> /Bruce

[dpdk-dev] [PATCH] Add an API to query enabled core index

[Lu, Patrick]

-Original Message-
From: Thomas Monjalon [mailto:thomas.monja...@6wind.com] 
Sent: Wednesday, June 11, 2014 2:51 PM
To: Lu, Patrick
Cc: dev at dpdk.org
Subject: Re: [dpdk-dev] [PATCH] Add an API to query enabled core index

Hi,

2014-06-11 13:45, Patrick Lu:
> EAL -c option allows the user to enable any lcore in the system.
> Oftentimes, the user app wants to know 1st enabled core, 2nd enabled 
> core, etc, rather than phyical core ID (rte_lcore_id().)
> 
> The new API rte_lcore_id2() will return an index from enabled lcores 
> starting from zero.

I think core_id2 is not a representative name.
What do you think of renaming core_id as lcore_hwid and core_id2 as lcore_index?

--
Thomas

I think this is a good idea. Except core_id is used in 13 other places. Should 
I resubmit the patch with core_id renamed it lcore_hwid?

Patrick