> On Dec 27, 2018, at 9:17 AM, Olivier Matz wrote:
>
> Hi,
>
> On Thu, Dec 27, 2018 at 02:52:51PM +0000, Wiles, Keith wrote:
>>
>>
>>> On Dec 27, 2018, at 8:47 AM, Wiles, Keith wrote:
>>>
>>>
>>>
>>>> On Dec
> On Jan 3, 2019, at 11:10 AM, Jason Messer wrote:
>
> +Jeffrey, Manasi
>
> We will get the most traction from the Windows developer community if we use
> msvc. The only thing preventing that last time was GNU extensions used in
> DPDK source which were not ISO C standards compliant. We were
> On Jan 9, 2019, at 4:25 PM, Daniel Waddington
> wrote:
>
> Hi,
> I'm trying to run DPDK 18.11 on IBM Power9. Should it run? (I'n new to DPDK
> on Power).
> Thx,
> Daniel
> Below is what I get:
>
> $ sudo ./examples/ethtool/ethtool-app/ppc_64-power8-linuxapp-gcc/app/ethtool
> --iova-mo
ror 22" which is the first
> indicator of the problem.
>
> Daniel
>
> -"Wiles, Keith" wrote: -
> To: Daniel Waddington
> From: "Wiles, Keith"
> Date: 01/09/2019 02:52PM
> Cc: "dev@dpdk.org"
> Subject: Re: [dpdk-dev] DPDK
> On Jan 9, 2019, at 6:07 PM, Thomas Monjalon wrote:
>
> Hi,
>
> 09/01/2019 23:25, Daniel Waddington:
>> Hi,
>> I'm trying to run DPDK 18.11 on IBM Power9. Should it run? (I'n new to
>> DPDK on Power).
>
> As mentioned in the release notes, Power9 is supported:
> http://doc.dpdk.org
o me
Anyway my email compiler is not very good and maybe this will not work.
We can leave the current design in place for now, till I have time to really
look at doing a PoC for my suggestion.
>
> Kindest regards,
> Raslan Darawsheh
>
> -Original Message-
> From: Wiles,
> On Oct 3, 2018, at 9:00 AM, Babu Radhakrishnan, AgalyaX
> wrote:
>
> Disabled tap build in FreeBSD because it is not supported
> Added changes to enable tap build if it is Linux OS and
> disable in FreeBSD.
>
> Signed-off-by: Agalya Babu RadhaKrishnan
>
Thought I acked this one already.
> On Sep 3, 2018, at 9:44 AM, Ilya Maximets wrote:
>
> For meson build without deprecation warnings following
> patch should be applied first:
>http://patches.dpdk.org/patch/44129/
Not to be super picky (OK I am super picky sometimes) can we change the name of
the function rte_delay_us_s
> On Oct 3, 2018, at 11:09 AM, Yigit, Ferruh wrote:
>
> On 8/3/2018 3:05 PM, keith.wiles at intel.com (Keith Wiles) wrote:
>> Signed-off-by: Keith Wiles
>> ---
>> lib/librte_eal/common/include/rte_common.h | 5 +
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/lib/librte_eal/common/
> On Oct 5, 2018, at 9:11 AM, Wiles, Keith wrote:
>
>
>
>> On Oct 3, 2018, at 11:09 AM, Yigit, Ferruh wrote:
>>
>> On 8/3/2018 3:05 PM, keith.wiles at intel.com (Keith Wiles) wrote:
>>> Signed-off-by: Keith Wiles
>>> ---
>>> lib/li
> On Oct 5, 2018, at 9:44 AM, Ilya Maximets wrote:
>
> On 05.10.2018 17:09, Wiles, Keith wrote:
>>
>>
>>> On Sep 3, 2018, at 9:44 AM, Ilya Maximets wrote:
>>>
>>> For meson build without deprecation warnings following
>>> patch sho
Hi Everyone,
I would like to request comments on DFS as I presented at the DPDK summit in
Ireland.
As we know DPDK can be difficult to manage at run time and as DPDK becomes more
dynamic we need to address how to configure and monitor DPDK and DPDK-based
applications. A possible solution is t
> On Oct 8, 2018, at 5:42 PM, Wiles, Keith wrote:
>
> Hi Everyone,
>
> I would like to request comments on DFS as I presented at the DPDK summit in
> Ireland.
Here is a repo you can look at and play with. The code is mostly ready for
upstream but still more work needs
> On Oct 10, 2018, at 2:01 AM, Raslan Darawsheh wrote:
>
> When writev fails to send packets it doesn't update the
> number of Tx packets, but it still num_tx is updated.
>
> the value that should be returned is the actual number
> of sent packets which is num_packets.
>
> Fixes: 02f96a0a ("
> On Oct 10, 2018, at 2:03 AM, Raslan Darawsheh wrote:
>
> In the case the device is created by the primary process,
> the secondary must request some file descriptors to attach the queues.
> The file descriptors are shared via IPC Unix socket.
>
> Thanks to the IPC synchronization, the secon
> On Oct 10, 2018, at 2:03 AM, Raslan Darawsheh wrote:
>
> Signed-off-by: Raslan Darawsheh
This title for the patch is the what we did not why we did it, should that be
changed? To me it does not convey the reason or we would need to add a more
complete comment body text to explain why we
> On Oct 9, 2018, at 5:52 PM, Wiles, Keith wrote:
>
>
>
>> On Oct 8, 2018, at 5:42 PM, Wiles, Keith wrote:
>>
>> Hi Everyone,
>>
>> I would like to request comments on DFS as I presented at the DPDK summit in
>> Ireland.
>
> Her
> On Jun 12, 2018, at 7:26 AM, Thomas Monjalon wrote:
>
> 11/06/2018 18:35, Wiles, Keith:
>>
>>> On Jun 11, 2018, at 11:06 AM, Ophir Munk wrote:
>>>
>>> This commit explains how to manually compile the C source file
>>> tap_bpf_program.c
> On Jun 7, 2018, at 6:24 PM, Raslan Darawsheh wrote:
>
> Hi,
>
> As you know that currently TAP pmd support attaching a secondary process to a
> primary process.
> But, it's still lacking the ability to do Rx/Tx burst since it's lacking the
> necessary fds for RX/TX queues,
> And the setti
> On Jun 12, 2018, at 7:58 AM, Thomas Monjalon wrote:
>
> 12/06/2018 14:36, Wiles, Keith:
>>
>>> On Jun 12, 2018, at 7:26 AM, Thomas Monjalon wrote:
>>>
>>> 11/06/2018 18:35, Wiles, Keith:
>>>>
>>>>> On Jun 11, 2018, at
> On Jun 12, 2018, at 8:44 AM, Thomas Monjalon wrote:
>
> 12/06/2018 15:33, Wiles, Keith:
>>
>>> On Jun 12, 2018, at 7:58 AM, Thomas Monjalon wrote:
>>>
>>> 12/06/2018 14:36, Wiles, Keith:
>>>>
>>>>> On Jun 12, 2018, at
A few formatting problems I have noticed. We can review the code logic in a
meeting.
> On Jun 12, 2018, at 11:31 AM, Ophir Munk wrote:
>
> Prior to this commit IP/UDP/TCP checksum offload calculations
> were skipped in case of a multi segments packet.
> This commit enables TAP checksum calculat
> On Jun 12, 2018, at 11:31 AM, Ophir Munk wrote:
>
> This commit implements TCP segmentation offload in TAP.
> librte_gso library is used to segment large TCP payloads (e.g. packets
> of 64K bytes size) into smaller MTU size buffers.
> By supporting TSO offload capability in software a TAP de
> On Jun 12, 2018, at 11:31 AM, Ophir Munk wrote:
>
> This commit implements TCP segmentation offload in TAP.
> librte_gso library is used to segment large TCP payloads (e.g. packets
> of 64K bytes size) into smaller MTU size buffers.
> By supporting TSO offload capability in software a TAP de
> On Jun 13, 2018, at 11:59 AM, Thomas Monjalon wrote:
>
> 13/06/2018 18:41, Ferruh Yigit:
>> On 6/8/2018 6:58 PM, Rahul Lakkireddy wrote:
>>> diff --git a/drivers/net/cxgbe/cxgbe_filter.h
>>> b/drivers/net/cxgbe/cxgbe_filter.h
>>> new file mode 100644
>>> index 0..d69c79e80
>>> --- /
> On Jun 14, 2018, at 2:59 AM, Ophir Munk wrote:
>
>
>
>> -Original Message-----
>> From: Wiles, Keith [mailto:keith.wi...@intel.com]
>> Sent: Wednesday, June 13, 2018 7:04 PM
>> To: Ophir Munk
>> Cc: DPDK ; Pascal Mazon ;
>> Thomas Monja
> On Jun 20, 2018, at 9:00 PM, Qi Zhang wrote:
>
> Previously, detach port on secondary process will mess primary
> process and cause same device can't be attached again, by take
> advantage of rte_eth_release_port_private, we can support this
> with minor change.
>
> Signed-off-by: Qi Zhang
> On Jun 23, 2018, at 6:17 PM, Ophir Munk wrote:
>
> Prior to this commit IP/UDP/TCP checksum offload calculations
> were skipped in case of a multi segments packet.
> This commit enables TAP checksum calculations for multi segments
> packets.
> The only restriction is that the first segment mu
ate "+#include "bpf_api.h", which includes a iproute2
>> header, I am not sure about this one and how to manage this dependency.
>
> If you feel it needs some improvement, we can postpone it for 18.11.
> The most important is to have a patch to reference when somebo
> On Oct 21, 2018, at 8:39 AM, Lewis Donzis wrote:
>
> Please consider changing “struct ether_addr” in rte_ether.h to “struct
> rte_ether_addr”, in order to avoid conflicts with the same structure name
> /usr/include/net/ethernet.h.
>
> This is kind of a pain for us since we would like to in
> On Oct 24, 2018, at 1:18 AM, Olivier Matz wrote:
>
> Add 'RTE_' prefix to defines:
> - rename ARP_HRD_ETHER as RTE_ARP_HRD_ETHER.
> - rename ARP_OP_REQUEST as RTE_ARP_OP_REQUEST.
> - rename ARP_OP_REPLY as RTE_ARP_OP_REPLY.
> - rename ARP_OP_REVREQUEST as RTE_ARP_OP_REVREQUEST.
> - rename AR
> On Oct 24, 2018, at 1:18 AM, Olivier Matz wrote:
>
> This RFC targets 19.02.
>
> The rte_net headers conflict with the libc headers, because
> some definitions are duplicated, sometimes with few differences.
> This was discussed in [1], and more recently at the techboard.
>
> Before sendin
> On Nov 2, 2018, at 6:31 AM, Burakov, Anatoly
> wrote:
>
> On 02-Nov-18 4:00 AM, Somnath Kotur wrote:
>> Hello,
>>I'm trying to launch a thread - lcore_mainloop( from
>> examples/timer/main.c ) that runs rte_manage_timer() every 2s from testpmd
>> to ensure the timers i've registered
> On Nov 2, 2018, at 9:35 AM, Wiles, Keith wrote:
>
>
Sorry, meant to hit cancel for my previous email, Anatoly answered it correctly.
Regards,
Keith
> On Nov 2, 2018, at 9:04 PM, Yongseok Koh wrote:
>
> This is a workaround to prevent a crash, which might be caused by
> optimization of newer gcc (7.3.0) on Intel Skylake.
Should the code below not also test for the gcc version and the Sky Lake
processor, maybe I am wrong but it seems it i
> On Nov 6, 2018, at 9:30 PM, Yongseok Koh wrote:
>
>
>> On Nov 5, 2018, at 6:06 AM, Wiles, Keith wrote:
>>
>>
>>
>>> On Nov 2, 2018, at 9:04 PM, Yongseok Koh wrote:
>>>
>>> This is a workaround to prevent a crash, which might
> On Nov 6, 2018, at 7:30 PM, Stephen Hemminger
> wrote:
>
> If netlink socket setup fails the file descriptor was leaked.
Acked-by: Keith Wiles
>
> Coverity issue: 257040
> Fixes: 7c25284e30c2 ("net/tap: add netlink back-end for flow API")
> Signed-off-by: Stephen Hemminger
> ---
> drive
> On Nov 6, 2018, at 7:30 PM, Stephen Hemminger
> wrote:
>
> Static analysis tools don't like the fact that fd could be zero
> in the error path. This won't happen in real world because
> stdin would have to be closed, then other error occurring.
Acked-by: Keith Wiles
>
> Coverity issue: 1
> On Nov 7, 2018, at 1:58 PM, Varghese, Vipin wrote:
>
> In scenarion for multiq or flowq setup failure rte_eth_dev_probing_finish
> has to be invoked for successful device registration.
>
Acked-by: Keith Wiles
> Signed-off-by: Vipin Varghese
> ---
> ---
> drivers/net/tap/rte_eth_tap.c | 1
Sent from my iPhone
> On Nov 7, 2018, at 2:36 AM, Jiang Huiyou wrote:
>
> Hi,
> My user-space TCP/IP stack works fine on DPDK 17.02, now I upgrade it to
> 18.02. And then I use wrk http benchmark to test my stack, it work well
> fine, but after a while, it couldn't send packet. I deb
> On Nov 14, 2018, at 4:51 AM, Morten Brørup wrote:
>
> Anatoly,
>
> This differs from the Linux kernel's behavior, where padding belongs in the
> NIC driver layer, not in the protocol layer. If you pass a runt frame (too
> short packet) to a Linux NIC driver's transmission function, the NIC
> On Nov 15, 2018, at 4:27 AM, Morten Brørup wrote:
>
>> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Wiles, Keith
>>> On Nov 14, 2018, at 4:51 AM, Morten Brørup
>> wrote:
>>>
>>> Anatoly,
>>>
>>> This differs from t
> On Nov 15, 2018, at 7:27 AM, Hunt, David wrote:
>
> Hi Anatoly,
>
> On 13/11/2018 4:42 PM, Anatoly Burakov wrote:
>> If there aren't any devices of a particular category on user's
>> system, we still display them, which is bad for usability. Fix
>> devbind to not print out a category unless
> On Nov 16, 2018, at 5:49 AM, Burakov, Anatoly
> wrote:
>
> On 16-Nov-18 12:45 AM, Stephen Hemminger wrote:
>> On Thu, 15 Nov 2018 15:47:13 +
>> Anatoly Burakov wrote:
>>> This is a placeholder for Python library abstracting away many of
>>> mundane details DPDK configuration scripts ha
On Nov 16, 2018, at 3:51 AM, Ananyev, Konstantin
mailto:konstantin.anan...@intel.com>> wrote:
Hi everyone,
Hi,
16/11/2018 09:42, Ilya Maximets:
Hi,
While discussing the ways to enable DPDK 18.11 new features in OVS
there was suggestions to use 'rte_eth_devices[]' array directly.
But this ar
> On Nov 16, 2018, at 3:51 AM, Ananyev, Konstantin
> wrote:
>
> Hi everyone,
>
>>
>> Hi,
>>
>> 16/11/2018 09:42, Ilya Maximets:
>>> Hi,
>>> While discussing the ways to enable DPDK 18.11 new features in OVS
>>> there was suggestions to use 'rte_eth_devices[]' array directly.
>>> But this a
> On Nov 16, 2018, at 8:37 AM, Burakov, Anatoly
> wrote:
>
> On 16-Nov-18 2:13 PM, Richardson, Bruce wrote:
>>> -Original Message-----
>>> From: Wiles, Keith
>>> Sent: Friday, November 16, 2018 2:10 PM
>>> To: Burakov, Anatoly
>
> On Nov 16, 2018, at 8:55 AM, Thomas Monjalon wrote:
>
> 16/11/2018 15:37, Burakov, Anatoly:
>> On 16-Nov-18 2:13 PM, Richardson, Bruce wrote:
>>> From: Wiles, Keith
>>>>> On Nov 16, 2018, at 5:49 AM, Burakov, Anatoly
>>>>> On 16-No
> On Nov 20, 2018, at 3:16 AM, Ananyev, Konstantin
> wrote:
>
> Hi Qi,
>
>> -Original Message-
>> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Qi Zhang
>> Sent: Tuesday, November 20, 2018 4:46 AM
>> To: Richardson, Bruce ; Wiles, Keit
> On Nov 19, 2018, at 10:45 PM, Zhang, Qi Z wrote:
>
> The patch optimizes the mac swap operation by taking advantage
> of SSE instructions, it only impacts x86 platform.
>
> Cc: sta...@dpdk.org
>
> Signed-off-by: Qi Zhang
> ---
> app/test-pmd/macswap.c | 16 +++-
> 1 file change
> On Nov 19, 2018, at 10:45 PM, Zhang, Qi Z wrote:
>
> The patch optimizes the mac swap operation by taking advantage
> of SSE instructions, it only impacts x86 platform.
>
> Cc: sta...@dpdk.org
>
> Signed-off-by: Qi Zhang
> ---
> app/test-pmd/macswap.c | 16 +++-
> 1 file change
> On Nov 23, 2018, at 4:43 PM, Wiles, Keith wrote:
>
>
>
>> On Nov 19, 2018, at 10:45 PM, Zhang, Qi Z wrote:
>>
>> The patch optimizes the mac swap operation by taking advantage
>> of SSE instructions, it only impacts x86 platform.
>>
>> Cc
> On Oct 8, 2018, at 5:42 PM, Wiles, Keith wrote:
>
> Hi Everyone,
>
> I would like to request comments on DFS as I presented at the DPDK summit in
> Ireland.
>
> As we know DPDK can be difficult to manage at run time and as DPDK becomes
> more dynamic we need
> On Nov 29, 2018, at 8:09 AM, bugzi...@dpdk.org wrote:
>
> https://bugs.dpdk.org/show_bug.cgi?id=113
>
>Bug ID: 113
> Summary: pktgen -s option send pcap traffic once
> Product: DPDK
> Version: unspecified
> Hardware: x86
>OS:
> On Nov 29, 2018, at 8:21 AM, Anatoly Burakov
> wrote:
>
> We already trigger a mem event notification inside the walk function,
> no need to do it twice.
>
> Fixes: f32c7c9de961 ("malloc: enable event callbacks for external memory")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Anatoly Burakov
> On Nov 29, 2018, at 9:36 AM, Burakov, Anatoly
> wrote:
>
> On 29-Nov-18 2:54 PM, Wiles, Keith wrote:
>>> On Nov 29, 2018, at 8:21 AM, Anatoly Burakov
>>> wrote:
>>>
>>> We already trigger a mem event notification inside the walk func
On Nov 30, 2018, at 7:13 AM, Zhang, Qi Z
mailto:qi.z.zh...@intel.com>> wrote:
Hi Keith:
-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Wiles, Keith
Sent: Tuesday, November 27, 2018 11:00 PM
To: dpdk-dev mailto:dev@dpdk.org>>
Cc: Richa
Plain text format is a real pain unless I time travel to the 1990’s :-(
> On Nov 30, 2018, at 7:13 AM, Zhang, Qi Z wrote:
>
> Hi Keith:
>
>
>> -Original Message-
>> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Wiles, Keith
>> Sent: Tuesday,
> On Jul 9, 2018, at 3:20 PM, Eads, Gage wrote:
>
> Set the rx and tx queue state appropriately when the queues or device are
> started or stopped.
>
> Signed-off-by: Gage Eads
> ---
> drivers/net/tap/rte_eth_tap.c | 56 +--
> 1 file changed, 54 inserti
> On Jul 9, 2018, at 4:51 PM, Eads, Gage wrote:
>
>
>
>>>
>>> +static int
>>> +tap_rx_queue_start(struct rte_eth_dev *dev, uint16_t rx_queue_id)
>>> +{
>>> + dev->data->rx_queue_state[rx_queue_id] =
>> RTE_ETH_QUEUE_STATE_STARTED;
>>
>> We need to verify the rx_queue_id is valid before s
> On Jul 9, 2018, at 3:20 PM, Eads, Gage wrote:
>
> Set the rx and tx queue state appropriately when the queues or device are
> started or stopped.
>
> Signed-off-by: Gage Eads
Acked-by Keith Wiles
Regards,
Keith
> On Jul 9, 2018, at 5:00 PM, Wiles, Keith wrote:
>
>
>
>> On Jul 9, 2018, at 4:51 PM, Eads, Gage wrote:
>>
>>
>>
>>>>
>>>> +static int
>>>> +tap_rx_queue_start(struct rte_eth_dev *dev, uin
What version of Pktgen and DPDK are you using?
Most likely DPDK has changed for the given version or Pktgen. I normally only
keep pktgen working on the last releases version 18.05 in this case.
I am over due pushing a updated version of pktgen, so I will try to get that
done soon.
> On Jul 11,
> On Jul 11, 2018, at 6:47 AM, khemendra kumar
> wrote:
>
> Hi All,
>
> Kindly help to check below compile error in DPDK Pkt-gen on x86.
>
> I am following instructions from "
> http://pktgen-dpdk.readthedocs.io/en/latest/getting_started.html";
>
> *Below cmd I followed:*
> sudo make config
> On Jul 11, 2018, at 8:21 AM, Wiles, Keith wrote:
>
>
>
>> On Jul 11, 2018, at 6:47 AM, khemendra kumar
>> wrote:
>>
>> Hi All,
>>
>> Kindly help to check below compile error in DPDK Pkt-gen on x86.
>>
>> I am following instru
r.
>
>
>
> Just to clarify my use case, I want to use Pktgen as TG for send traffic to
> VPP.
> Both Pktgen and VPP will be running on 2 ARM machines (ARMv8).
>
>
> Thanks & Regards
> Khem
>
> On Wed, Jul 11, 2018 at 7:47 PM, Wiles, Keith wrote:
>
> On Jul 11, 2018, at 4:21 PM, Mattias Rönnblom
> wrote:
>
> This is the Distributed Software (DSW) event device, which distributes
> the task of scheduling events among all the eventdev ports and their
> lcore threads.
>
> DSW is primarily designed for atomic-only queues, but also supports
>
> On Jul 13, 2018, at 12:10 PM, Burakov, Anatoly
> wrote:
>
> On 06-Jul-18 2:17 PM, Anatoly Burakov wrote:
>> This is a proposal to enable using externally allocated memory
>> in DPDK.
>> In a nutshell, here is what is being done here:
>> - Index malloc heaps by NUMA node index, rather than NU
> On Jul 17, 2018, at 10:43 PM, wubenq...@ruijie.com.cn wrote:
>
> Hi~
>Reference:
> http://doc.dpdk.org/guides-18.05/sample_app_ug/performance_thread.html?highlight=lthread
>The L-thread subsystem provides a set of functions that are logically
> equivalent to the corresponding functio
de is somewhat different then the code in DPDK and my changes would
not apply to DPDK lthreads.
>
> So I think there is a problem with pthread_cond_wait implemented by lthread.
> If that is the case, could lthread fix this problem?
>
> Regards,
> Wubenqing
>
> On Jul 20, 2018, at 4:15 AM, Thomas Monjalon wrote:
>
> From: Raslan Darawsheh
>
> In the case the device is created by the primary process,
> the secondary must request some file descriptors to attach the queues.
> The file descriptors are shared via IPC Unix socket.
>
> Thanks to the IP
> On Jul 20, 2018, at 4:51 PM, Thomas Monjalon wrote:
>
> 20/07/2018 17:35, Wiles, Keith:
>>> On Jul 20, 2018, at 4:15 AM, Thomas Monjalon wrote:
>>> + /* FIXME: handle replies.nb_received > 1 */
>>
>> I am not a big fan of having TODO or FIXME
> On Jul 20, 2018, at 8:32 PM, wubenq...@ruijie.com.cn wrote:
>
> Hi~
> I would be appreciate it if you could provide your lthread code for me.
> And I found that DPDK lthreads does not provide lthread_cond_timedwait API
> which I am looking for.
> Thanks.
I took the lthread code and
> On Jul 23, 2018, at 2:09 PM, Morten Brørup wrote:
>
> I haven't performance tested, but they are compiler branch prediction hints
> pointing out the most likely execution path, so I expect them to have a
> positive effect.
We really need to make sure this provides any performance improveme
> On Jul 24, 2018, at 6:31 AM, Van Haaren, Harry
> wrote:
>
>> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Morten Brørup
>> Sent: Tuesday, July 24, 2018 9:14 AM
>> To: Olivier Matz ; Wiles, Keith
>>
>> Cc: Honnappa Nagarahalli ; dev@dpdk.
> On Jul 24, 2018, at 12:05 AM, Vipin Varghese wrote:
>
> Invoke rte_eth_dev_probing_finish for rte_pmd_tun_probe.
>
> Signed-off-by: Vipin Varghese
> ---
> drivers/net/tap/rte_eth_tap.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/net/tap/rte_eth_tap.c b/drivers/net/tap/
> On Jul 19, 2018, at 7:21 AM, ilia.kura...@intel.com wrote:
>
> From: Ilia Kurakin
>
> The patch changes rx_burst profiling approach:
> 1. VTune's instrumentation is removed
> 2. empty hook callback for profiling is added
> This way all VTune-specific logic moves to the VTune sid
> On Jul 28, 2018, at 12:48 PM, Qiaobin Fu wrote:
>
> Function rte_hash_bucket_iterate() enables callers to
> incrementally iterate over the hash table bucket by bucket,
> so that it can avoid creating hiccups and thrashing the cache
> of the processor.
>
> This patch mainly deals with cases i
is no different. If we can
hide the internals, then it would be good. The callback function should not
expose any internals only the value in the hash table, which I believe is do
just that, right?
>
> Hope this clarifies the patch.
>
> Best,
> Qiaobin
>
>>
>>> ---
> On Aug 1, 2018, at 7:07 AM, Burakov, Anatoly
> wrote:
>
> Due to the upcoming external memory support [1], some API and ABI
> changes will be required. In addition, although the changes called
> out in the deprecation notice are not yet present in form of code
> in the published RFC itself,
> On Aug 2, 2018, at 5:33 AM, Matan Azrad wrote:
>
> The rte_flow meaning of zero flow mask configuration is to match all
> the range of the item value.
> For example, the flow eth / ipv4 dst spec 1.2.3.4 dst mask 0.0.0.0
> should much all the ipv4 traffic from the rte_flow API perspective.
>
> On Jul 31, 2018, at 5:33 AM, Shreyansh Jain wrote:
>
> Rawdev queue count API prototype was declared, but the definition was
> missing from the library. This patch implements the function.
>
> This API is used to query the device about the count of queues it has
> been configured with.
>
>
> On Jul 31, 2018, at 5:33 AM, Shreyansh Jain wrote:
>
> Use the rte_rawdev_queue_count API in skeleton and add its unit test
> case.
>
> Signed-off-by: Shreyansh Jain
> ---
> drivers/raw/skeleton_rawdev/skeleton_rawdev.c | 13 +
> drivers/raw/skeleton_rawdev/skeleton_rawdev_
> On Aug 16, 2018, at 10:31 AM, Stephen Hemminger
> wrote:
>
> The hexdump code obviously came from somewhere else originally.
> It is not formatted according to DPDK coding style.
>
> Also, drop the comment which is not useful the docbock comment
> is already in the rte_hexdump.h
>
> Signe
> On Aug 16, 2018, at 10:31 AM, Stephen Hemminger
> wrote:
>
> The hexdump code obviously came from somewhere else originally.
> It is not formatted according to DPDK coding style.
>
> Also, drop the comment which is not useful the docbock comment
> is already in the rte_hexdump.h
>
> Signed
I am building on Ubuntu 18.04.1 LTS, gcc 7.3.0-16ubuntu3 and with
EXTRA_CFLAGS=“-g -O0” with shared libs enabled.
I get an undefined reference to rte_dpaa2_memsegs when building
portal/dpaa2_hw_dpio.c in the link phase.
The odd part is this does not happen unless you are building with EXTRA_CF
> On Aug 20, 2018, at 2:33 AM, Hemant Agrawal wrote:
>
> Hi Keith,
> I am able to reproduce the issue. We will send the fix asap.
Thanks Hemant.
>
> Regards,
> Hemant
>
> -Original Message-
> From: dev On Behalf Of Wiles, Keith
> Sent: Sun
> On Aug 20, 2018, at 3:46 AM, Kevin Wilson wrote:
>
> Hi all,
> Maybe this is a silly question, please bear with me.
>
> According to the “Getting Started Guide for Linux” in
> http://doc.dpdk.org/guides/linux_gsg/sys_reqs.html,
> the kernel version should be >= 3.2.
> Accrding to my understa
> On Aug 20, 2018, at 9:47 AM, Matteo Lanzuisi wrote:
>
> Hello Olivier,
>
> Il 13/08/2018 23:54, Olivier Matz ha scritto:
>> Hello Matteo,
>>
>> On Mon, Aug 13, 2018 at 03:20:44PM +0200, Matteo Lanzuisi wrote:
>>> Any suggestion? any idea about this behaviour?
>>>
>>> Il 08/08/2018 11:56,
> On Aug 21, 2018, at 7:01 AM, Matteo Lanzuisi wrote:
>
> Hi
>
> Il 20/08/2018 18:03, Wiles, Keith ha scritto:
>>> On Aug 20, 2018, at 9:47 AM, Matteo Lanzuisi
>>> wrote:
>>>
>>> Hello Olivier,
>>>
>>> Il 13/08/2018
> On Aug 21, 2018, at 7:44 AM, Matteo Lanzuisi wrote:
>
> Il 21/08/2018 14:17, Wiles, Keith ha scritto:
>>
>>> On Aug 21, 2018, at 7:01 AM, Matteo Lanzuisi wrote:
>>>
>>> Hi
>>>
>>> Il 20/08/2018 18:03, Wiles, Keith ha
> On Aug 18, 2018, at 6:58 AM, Chengbo CB1 Gao wrote:
>
> Hi Team,
>
> When I used PKTGEN by X710VF, I found that PKTGEN failed to be initialized.
> The reason is that VF has no ability to disable HW CRC strip. But it's
> defaulted to be disabled in PKTGEN because the global variable(hw_stri
; // don't use mempool but call a function instead
> }
> }
>
> and now it all goes well.
> It is possibile that sending to itself could generate this issue?
>
> Regards,
> Matteo
>
> Il 21/08/2018 16:46, Matteo Lanzuisi ha scritto:
>&
Which version of Pktgen? I just pushed a patch in 3.5.3 to fix a performance
problem.
> On Aug 28, 2018, at 12:05 PM, Saber Rezvani wrote:
>
>
>
> On 08/28/2018 08:31 PM, Stephen Hemminger wrote:
>> On Tue, 28 Aug 2018 17:34:27 +0430
>> Saber Rezvani wrote:
>>
>>> Hi,
>>>
>>>
>>> I have
> On Aug 28, 2018, at 2:16 PM, Saber Rezvani wrote:
>
>
>
> On 08/28/2018 11:39 PM, Wiles, Keith wrote:
>> Which version of Pktgen? I just pushed a patch in 3.5.3 to fix a
>> performance problem.
> I use Pktgen verion 3.0.0, indeed it is O.k as far as I h
> On Aug 29, 2018, at 12:19 PM, Saber Rezvani wrote:
>
>
>
> On 08/29/2018 01:39 AM, Wiles, Keith wrote:
>>
>>> On Aug 28, 2018, at 2:16 PM, Saber Rezvani wrote:
>>>
>>>
>>>
>>> On 08/28/2018 11:39 PM, Wiles, Keith wrot
> On Apr 18, 2018, at 8:50 AM, Thomas Monjalon wrote:
>
> 18/04/2018 10:56, Bruce Richardson:
>> On Wed, Apr 18, 2018 at 12:19:07AM +0200, Thomas Monjalon wrote:
>>> 18/04/2018 00:11, Scott Branden:
On 18-04-17 03:06 PM, Thomas Monjalon wrote:
> 17/04/2018 23:49, Stephen Hemminger:
>>>
> On Apr 18, 2018, at 11:43 AM, Shailja Pandey wrote:
>
> Hello,
>
> I am doing packet replication and I need to change the ethernet and IP header
> field for each replicated packet. I did it in two different ways:
>
> 1. Share payload from the original packet using rte_mbuf_refcnt_update
>
> On Apr 19, 2018, at 9:30 AM, Shailja Pandey wrote:
>
>> The two code fragments are doing two different ways the first is using a
>> loop to create possible more then one replication and the second one is not,
>> correct? The loop can cause performance hits, but should be small.
> Sorry for
> On Aug 31, 2018, at 1:45 PM, Ilya Maximets wrote:
>
> NICs uses different delays up to a second during their
> configuration. It makes no sense to busy-wait so long wasting
> CPU cycles and preventing any other threads to execute on the
> same CPU core. These busy polling are the rudiments t
301 - 400 of 885 matches
Mail list logo
