On 1/20/16 10:14 PM, Qiu, Michael wrote:
> As we could start up many primaries, how does your secondary process
> work with them?
I just worked on this tonight myself. When doing > 1 primary (for
example pktgen and app), I had to specify:
--no-shconf
--file-prefix pktgen
--file-prefix app
Or yo
Hello,
I was trying to just use the default PKT file, test/set_seq.pkt, like so:
sudo "./app/app/${RTE_TARGET}/pktgen" \
-l 2,3 \
--master-lcore 2 \
-n 2 \
-m 1024 \
-w 0a:00.1 \
--no-shconf \
--file-prefix pktgen \
-- \
-P \
-m 2.0 \
-f test/set_seq.pkt
After pktgen loaded, the port 0 is marked
On 1/20/16 10:00 PM, Arnon Warshavsky wrote:
> Black background gets me to the blind reset as well.
> Pktgen is the only tab I keep with non black background..
Thanks for confirming. Never had this many termio issues before so I was
wondering if I just went totally crazy!
Matthew.
If I try using pktgen theme mode (-T) or unmodified, without commenting
out some of the stuff I mentioned I disabled for debugging in the
previous thread, it seems like it sets the pktgen prompt to be invisible
(black text on black??? or I'm not sure just want) on my TTY which has a
black backg
Signed-off-by: Matthew Hall
---
docs/source/usage_pktgen.rst | 15 +++
1 file changed, 15 insertions(+)
diff --git a/docs/source/usage_pktgen.rst b/docs/source/usage_pktgen.rst
index efe8aa4..223d033 100644
--- a/docs/source/usage_pktgen.rst
+++ b/docs/source/usage_pktgen.rst
@@ -157
Signed-off-by: Matthew Hall
---
docs/source/usage_pktgen.rst | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/docs/source/usage_pktgen.rst b/docs/source/usage_pktgen.rst
index 20bd314..efe8aa4 100644
--- a/docs/source/usage_pktgen.rst
+++ b/docs/source/usage_
On 1/20/16 7:27 AM, Thomas Monjalon wrote:
> Hi Matthew,
>
> RTE_SDK_BIN is an internal variable and should not be overriden.
>
> Have you installed DPDK somewhere? Example:
> make install O=mybuild DESTDIR=mylocalinstall
>
> Then you should build your app like this:
> make RTE_SDK=$(r
Hello,
> For this case, please use --single-file option because it creates much more
> than 8 fds, which can be handled by vhost-user sendmsg().
Thanks, I'm able to verify it by sending ARP packet from container to
host on arm64. But sometimes, I do see following message while running
l2fwd in co
Hi Jingjing,
As I can see this patch not only splits fdir functionality from common
fdir/hash code but also removes compatibility with DPDK 2.2 as it deletes
I40E_INSET_FLEX_PAYLOAD from valid fdir input set values. Yes, flexible payload
configuration can be set for fdir separately at the port
On 1/20/16 8:26 AM, Wiles, Keith wrote:
> One problem is a number of people wanted to steal the code and use in a paid
> application, so the copyright is some what a requirement. As you may know I
> do a lot of debugging on Pktgen and I feel they are a nuisance. I can try to
> see if we can clea
Sorry. It's L2 forwarding.
I used testpmd with forwarding mode, like
testpmd --pci-blacklist :00:05.0 -c f -n 4 -- --portmask 3 -i
--total-num-mbufs=2 --nb-cores=3 --mbcache=512 --burst=512
--forward-mode=mac --eth-peer=0,90:e2:ba:9f:95:94
--eth-peer=1,90:e2:ba:9f:95:95
On Wed, Jan 20, 2
Hello,
I was just reading the following blog post about downscaling community
involvement at the Linux Foundation.
http://mjg59.dreamwidth.org/39546.html
I wondered if any of issues discussed there this might be relevant for
the governance efforts moving forward on DPDK?
Sincerely,
Matthew.
I see that some of the rte_eth_stats have been marked deprecated in 2.2 that
are returned by rte_eth_stats_get(). Applications that utilize any number of
device types rely on functions like this one to debug I/O issues.
Is there a reason the stats have been deprecated? Why not keep the stats i
Hi Ivan,
> -Original Message-
> You would be right... if the PMDs did not transparently strip the CRC in
> software when hardware CRC stripping is disabled at port configuration (as
> described above).
> See for instance how the function ixgbe_recv_pkts_lro() in file
> drivers/net/ixgbe/i
Currently, the example vmdq_dcb only works on Intel? 82599 NICs.
This patch extended this sample to make it work both on Intel? 82599
and X710/XL710 NICs by following changes:
1. add VMDQ base queue checking to avoid forwarding on PF queues.
2. assign each VMDQ pools with MAC address.
3. add
The multi queue mode ETH_MQ_RX_VMDQ_DCB_RSS is not supported in
ixgbe driver. This patch added the checking.
Signed-off-by: Jingjing Wu
---
drivers/net/ixgbe/ixgbe_ethdev.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.
Previously, DCB is only enabled on PF, queue mapping and BW
configuration is only done on PF vsi. This patch enabled DCB
for VMDQ vsis by following steps:
1. Take BW and ETS configuration on VEB.
2. Take BW and ETS configuration on VMDQ vsis.
3. Update TC and queues mapping on VMDQ vsis.
To enab
Currently, the example vmdq_dcb only works on Intel? 82599 NICs.
This patch set extended this sample to make it works both on
Intel? 82599 and X710/XL710 NICs. This patch set also enabled
DCB VMDQ mode in i40e driver and added unsupported mode checking
in ixgbe driver.
Jingjing Wu (3):
i40e: en
On 01/20/2016 04:02 PM, Montorsi, Francesco wrote:
> Hi all,
>
> I need to get access to the Ethernet CRC of received packets.
> To do this, I'm configuring:
>
> port_conf.rxmode.hw_strip_crc = 0;
>
> Now my question is: how am I supposed to access the Ethernet CRC from a DPDK
> mbuf?
> Is the CRC
On 1/20/16, 10:26 AM, "dev on behalf of Wiles, Keith" wrote:
>On 1/20/16, 12:32 AM, "dev on behalf of Matthew Hall" on behalf of mhall at mhcomputing.net> wrote:
>
>>Hello,
Please try modifying pktgen-main.c:main() at the top of the function to this:
wr_scrn_setw(1);/* Reset the
Hi Matthew,
RTE_SDK_BIN is an internal variable and should not be overriden.
2016-01-19 21:30, Matthew Hall:
> Currently pktgen-dpdk and many other external apps will fail to compile
> if the build output directory name is not equal to the target name.
>
> This causes problems if you used an alt
On 1/20/16, 12:32 AM, "dev on behalf of Matthew Hall" wrote:
>Hello,
>
>Since the pktgen code is reindented I am finding time to read through it
>and experiment and see if I can get it working.
>
>I have issues with the init process of pktgen. It is difficult to debug
>it because the init code
2016-01-20 10:03, Kyle Larose:
> Hi Harry,
>
> On Wed, Jan 20, 2016 at 9:45 AM, Van Haaren, Harry
> wrote:
> > Hi Kyle,
>
> >
> > In theory we could create a new API for this, but I think the current
> > xstats API is a good fit for exposing this info, so why create extra APIs?
> > As a client
On 1/20/16, 12:32 AM, "dev on behalf of Matthew Hall" wrote:
Hi Matthew,
I have some comments below, but will address your full email later when I have
a bit more time.
>Hello,
>
>Since the pktgen code is reindented I am finding time to read through it
>and experiment and see if I can get it
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> 2016-01-20 10:03, Kyle Larose:
> > We already have the rte_eth_link_get function. Why not let users
> > continue to use that? It's well defined, it is simple, and it is
> > consistent.
>
> +1
Ok, no problem. I'll mark the link-statu
Hello,
Yes, you are right. Even if VLAN filtering is configured most of the
time during initialization, we should managed the case of multiple MAC
addresses already configured.
I will send you a v2 patch with this modification, use ether_addr_copy
and add additional debug messages.
Regards,
This patch adds a function that exposes keepalive statistics
re-using the existing rte_eth_xstats struct. The function provides
the client API the opportunity to read last-seen and status of
each core.
Signed-off-by: Harry van Haaren
---
doc/guides/rel_notes/release_2_3.rst| 6
This patch sets a timestamp on each lcore when it is registered
for keepalive. This causes the first values read by the monitor
to show time since the core was registered, instead of the delta
between 0 and the timestamp counter.
Signed-off-by: Harry van Haaren
---
lib/librte_eal/common/rte_keep
This patch fixes some mismatches between the keepalive code
and the docs. Struct names, and descriptions are not in line
with the codebase.
Fixes: e64833f2273a ("examples/l2fwd-keepalive: add sample application")
Signed-off-by: Harry van Haaren
---
doc/guides/sample_app_ug/keep_alive.rst | 19 +
This patchset contains:
1. Fix variable naming consistency in sample guide
2. Set last_seen time on core when it gets registered
3. An xstats implementation for last-seen and current core status
Harry van Haaren (3):
doc: fix keepalive sample app guide
eal: add keepalive core register timestam
I am running dpdk within a virtual guest as a L3 forwarder.
The VM has two ports connecting to two linux bridges (in turn connecting
two physical ports). DPDK is used to forward between these two ports (one
port connected to traffic generator and the other connected to sink). I
used iperf to test
Hi all,
I need to get access to the Ethernet CRC of received packets.
To do this, I'm configuring:
port_conf.rxmode.hw_strip_crc = 0;
Now my question is: how am I supposed to access the Ethernet CRC from a DPDK
mbuf?
Is the CRC just the 4 final bytes of the packets?
Is this correct:
uint
Hi Kyle,
> From: Kyle Larose [mailto:eomereadig at gmail.com]
> On Wed, Jan 20, 2016 at 9:28 AM, Harry van Haaren
> wrote:
> > This patch exposes link duplex, speed, and status via the
> > existing xstats API.
>
> I'm slightly confused by this. Why are we exposing operational
> properties of the
Hi Uday,
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of
> ravulakollu.kumar at wipro.com
> Sent: Wednesday, January 20, 2016 12:06 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] How classification happens in scheduling ?
>
> Hi all,
>
> Could someone expl
This patch exposes link duplex, speed, and status via the
existing xstats API.
Signed-off-by: Harry van Haaren
---
doc/guides/rel_notes/release_2_3.rst | 1 +
lib/librte_ether/rte_ethdev.c| 29 ++---
2 files changed, 27 insertions(+), 3 deletions(-)
diff --git a
This patch adds a new function to the EAL API:
int rte_eal_primary_proc_alive(const char *path);
The function indicates if a primary process is alive right now.
This functionality is implemented by testing for a write-
lock on the config file, and the function tests for a lock.
The use case for t
I found DMAR errors while bringing up other ports except port 0.
So rebooting the kernel with intel_iommu=off fixes it and dpdk i40e
initializes fine for all ports.
For some reason, the intel qcu64e mode change utility doesn't work if I
want to change back the mode from 4x10 to 2x40.
Tried several
Hi all,
Could someone explain me how this code snippet determining
subport,pipe,traffic_class,queue,color.
uint16_t *pdata = rte_pktmbuf_mtod(m, uint16_t *); //points to the
start of the data in the mbuf
*subport = (rte_be_to_cpu_16(pdata[SUBPORT_OFFSET]) & 0x0FFF)
&(port_para
Hi Wojciech,
Couple of nits, see below.
Konstantin
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Wojciech Andralojc
> Sent: Wednesday, January 20, 2016 10:57 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH v2] Patch introducing API to read/write Inte
This patch fixes the socket-id error in ip_pipeline sample
application running over uni-processor systems.
Signed-off-by: Jasvinder Singh
Acked-by: Cristian Dumitrescu
---
examples/ip_pipeline/init.c | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/examples
Patch rework based on feedback, only x86 specific functions left under
lib/librte_eal/common/include/arch/x86/.
Signed-off-by: Wojciech Andralojc
---
lib/librte_eal/common/include/arch/x86/rte_msr.h | 158 +++
1 file changed, 158 insertions(+)
create mode 100644 lib/librte_
On 01/20/2016 08:32 AM, Matthew Hall wrote:
> Hello,
>
> Since the pktgen code is reindented I am finding time to read through it
> and experiment and see if I can get it working.
>
> I have issues with the init process of pktgen. It is difficult to debug
> it because the init code does a lot of ve
From: Kamil Rytarowski
Currently rte_eal_check_module() detects Linux kernel modules via reading
/proc/modules. Built-in ones aren't listed there and therefore they are not
being found by the script.
Add support for checking built-in modules with parsing the sysfs files
This commit obsoletes th
From: Kamil Rytarowski
Currently dpdk_nic_bind.py detects Linux kernel modules via reading
/proc/modules. Built-in ones aren't listed there and therefore they are not
being found by the script.
Add support for checking built-in modules with parsing the sysfs files.
This commit obsoletes the /pr
On Wed, Jan 20, 2016 at 03:18:11AM +0800, Jianfeng Tan wrote:
> Issue description: when packets go through vhost example to virtio
> device and come back to another virtio device or physical NIC, the
> sequence of packets will be changed.
>
> Reported-by: Thomas Long
> Signed-off-by: Jianfeng Tan
On Tue, Jan 19, 2016 at 01:35:14PM -0800, Stephen Hemminger wrote:
> On Tue, 19 Jan 2016 15:56:14 -0500
> Neil Horman wrote:
>
> > On Tue, Jan 19, 2016 at 08:10:19AM -0800, Stephen Hemminger wrote:
> > > On Tue, 19 Jan 2016 09:29:31 -0500
> > > Neil Horman wrote:
> > >
> > > > On Tue, Jan 19, 2
On Wed, 20 Jan 2016 16:13:34 +0100
Thomas Monjalon wrote:
> > We already have the rte_eth_link_get function. Why not let users
> > continue to use that? It's well defined, it is simple, and it is
> > consistent.
+1
API's should not duplicate results (DRY)
That said, it would be useful to hav
On Wed, 20 Jan 2016 11:01:17 +
Jasvinder Singh wrote:
> +static inline int
> +app_get_cpu_socket_id(uint32_t pmd_id)
> +{
> + int status = rte_eth_dev_socket_id(pmd_id);
> +
> + if (status == -1)
> + return 0;
> +
> + return status;
> +
Why not:
return (status !=
Hi Harry,
On Wed, Jan 20, 2016 at 9:45 AM, Van Haaren, Harry
wrote:
> Hi Kyle,
>
> In theory we could create a new API for this, but I think the current xstats
> API is a good fit for exposing this info, so why create extra APIs? As a
> client of the DPDK API, I would prefer more statistics in
On Wed, Jan 20, 2016 at 9:28 AM, Harry van Haaren
wrote:
> This patch exposes link duplex, speed, and status via the
> existing xstats API.
>
I'm slightly confused by this. Why are we exposing operational
properties of the chip through an API which I thought was primarily
targeting statistics? Wh
Hi Matthew,
I hope that is what you are looking for:
http://dpdk.org/dev/patchwork/project/dpdk/list/?submitter=37&state=*&archive=both
You just click on Filters and there are few options...
Andriy
On Wed, Jan 20, 2016 at 6:20 AM, Matthew Hall wrote:
> I have some outstanding minor patches whi
> -Original Message-
> From: Julien Meunier [mailto:julien.meunier at 6wind.com]
> Sent: Tuesday, January 19, 2016 1:19 AM
> To: Zhang, Helin
> Cc: dev at dpdk.org
> Subject: [PATCH] i40e: fix vlan filtering
>
> VLAN filtering was always performed, even if hw_vlan_filter was disabled.
>
It works as expected, thanks.
Tested-by Yulong.pei at intel.com
Best Regards
Yulong Pei
-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Julien Meunier
Sent: Tuesday, January 19, 2016 1:19 AM
To: Zhang, Helin
Cc: dev at dpdk.org
Subject: [dpdk-dev] [PATCH] i40e: f
On 1/12/2016 1:37 PM, Tetsuya Mukawa wrote:
> Hi Jianfeng and Xie,
>
> I guess my implementation and yours have a lot of common code, so I will
> try to rebase my patch on yours.
>
> BTW, one thing I need to change your memory allocation way is that
> mmaped address should be under 44bit(32 + PAGE_
On 1/20/2016 2:33 AM, Polehn, Mike A wrote:
> SMP operations can be very expensive, sometimes can impact operations by 100s
> to 1000s of clock cycles depending on what is the circumstances of the
> synchronization. It is how you arrange the SMP operations within the tasks at
> hand across the S
Issue description: when packets go through vhost example to virtio
device and come back to another virtio device or physical NIC, the
sequence of packets will be changed.
Reported-by: Thomas Long
Signed-off-by: Jianfeng Tan
---
examples/vhost/main.c | 4 ++--
1 file changed, 2 insertions(+), 2
Adding RTE_KDRV_VFIO_NOIOMMU mode in kernel driver. Also including
rte_vfio_is_noiommu() helper function. This function will parse
/sys/bus/pci/device// and make sure that
- vfio noiommu mode set in kernel driver
- pci device attached to vfio-noiommu driver only
If both condition satisfies then se
Hi Huawei,
On 1/4/2016 10:46 PM, Huawei Xie wrote:
> This patch removes the internal lockless enqueue implmentation.
> DPDK doesn't support receiving/transmitting packets from/to the same
> queue. Vhost PMD wraps vhost device as normal DPDK port. DPDK
> applications normally have their own lock im
On Tue, Jan 19, 2016 at 7:48 PM, Burakov, Anatoly
wrote:
> Hi Santosh,
>
>> +int
>> +pci_vfio_is_noiommu(struct rte_pci_device *pci_dev) {
>> + FILE *fp;
>> + struct rte_pci_addr *loc;
>> + const char *path =
>> "/sys/module/vfio/parameters/enable_unsafe_noiommu_mode";
>> + char fi
59 matches
Mail list logo
