On 2016-06-21 15:11, Ferruh Yigit wrote:
> On 6/20/2016 5:19 PM, Stephen Hemminger wrote:
>> On Mon, 20 Jun 2016 12:44:35 +0200
>> Simon Kagstrom wrote:
>>
>>> I.e., avoid dump messages with double 0x0x, e.g.,
>>>
>>> dump mbuf at 0x0x7fac7b17c800, phys=17b17c880, buf_len=2176
>>>
Hi again!
Any news about this patch? I'm off for parental leave starting next week
(until january), so any comments (or simply dropping it!) would be good
to have before that :-)
// Simon
On 2016-06-10 08:29, Simon Kagstrom wrote:
> Signed-off-by: Simon Kagstrom
> ---
> I'm a total newbie to
Ping? Any more comments on this?
// Simon
On 2016-05-16 15:16, Simon K?gstr?m wrote:
> On 2016-05-16 14:43, Pattan, Reshma wrote:
This was added to allow devices, at least with one direction (RX/TX)
>>> supported. As, devices with both directions disabled doesn't make sense
>>> right?
Thanks for adding this, I've been missing this function!
On 2016-05-16 21:56, Walker, Benjamin wrote:
> On Mon, 2016-05-16 at 16:57 +, Wiles, Keith wrote:
>> The big question is how do you know the mempool is not being used someplace?
>
> That's the user's responsibility. Use after free is
On 2016-05-16 14:43, Pattan, Reshma wrote:
>>> This was added to allow devices, at least with one direction (RX/TX)
>> supported. As, devices with both directions disabled doesn't make sense
>> right?
>>
>> Well, not for running them, no. But this is a part of the shutdown procedure
>> between
On 2016-05-16 12:24, Pattan, Reshma wrote:
>> diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
>> index
>> a31018e..5481d45 100644
>> --- a/lib/librte_ether/rte_ethdev.c
>> +++ b/lib/librte_ether/rte_ethdev.c
>> @@ -944,11 +944,6 @@ rte_eth_dev_configure(uint8_t port_id,
On 2016-04-11 20:53, Thomas Monjalon wrote:
> 2016-04-11 11:15, Stephen Hemminger:
>> On Mon, 11 Apr 2016 12:46:16 +0200
>> Simon K?gstr?m wrote:
>>> In file included from [...]lib/librte_table/rte_table_lpm.c:43:0:
>>> [...]/dpdk.build/include/rte_lpm.h:484:25: fatal error: rte_lpm_sse.h:
>>> No
Hi!
I'm upgrading from DPDK 2.1 to 16.04-rc4, and have a new build issue
which I didn't see before. It's in the librte_table and happens from
time to time (unfrequently) in my out-of-tree build. It looks like a
race between comilation and SYMLINK-FILE:
[...]
== Build lib/librte_table
CC
On 2016-03-03 10:28, Thomas Monjalon wrote:
> 2016-03-03 08:53, Simon K?gstr?m:
>> I realize this is a more general question, but is it really meaningful
>> to have macros for all possible link speeds? We're working on a PMD
>> driver with a channelized interface exposed as DPDK ports. Each
Hi!
On 2016-03-03 05:08, Stephen Hurd wrote:
> Add additional ETH_LINK_SPEED_* macros for 2, 2.5, 25, and 50 Gbps links
>
> Signed-off-by: Stephen Hurd
> ---
> lib/librte_ether/rte_ethdev.h | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/lib/librte_ether/rte_ethdev.h
On 2015-12-07 13:56, Panu Matilainen wrote:
> Starting with commit 9aa2053c6e81493b23346ff4e387903560de5c81
> EXTRA_CFLAGS is sometimes being passed to the compiler without
> WERROR_FLAGS which can cause spurious warnings by the dozen,
> for example with when compiling with
On 2015-12-07 09:33, Panu Matilainen wrote:
> On 12/04/2015 08:53 PM, Thomas Monjalon wrote:
> We have encountered a CPU where the AES-NI instruction set is disabled
> due to export restrictions. Since the build machine and target machine
> is different, using -native configs doesn't
Hi Olivier!
Does this commit look OK now with the changes you proposed?
Thanks,
// Simon
On 2015-11-24 08:50, Simon Kagstrom wrote:
> We have encountered a CPU where the AES-NI instruction set is disabled
> due to export restrictions. Since the build machine and target machine
> is different,
On 2015-11-04 19:14, Stephen Hemminger wrote:
> On Wed, 28 Oct 2015 10:56:33 +0100
> Simon Kagstrom wrote:
>
>> Otherwise mbufs will leak when the port is destroyed. The
>> rte_sched_port_qbase() and rte_sched_port_qsize() functions are used
>> in free now, so move them up.
>>
>> Signed-off-by:
On 2015-11-04 19:21, Stephen Hemminger wrote:
> On Wed, 4 Nov 2015 12:29:01 +0100
> Simon K?gstr?m wrote:
>
>> On 2015-11-04 11:35, Thomas Monjalon wrote:
>>> 2015-08-20 08:51, Simon Kagstrom:
-ifeq ($(shell test -f /proc/version_signature && lsb_release -si
2>/dev/null),Ubuntu)
On 2015-11-04 11:35, Thomas Monjalon wrote:
> 2015-08-20 08:51, Simon Kagstrom:
>> -ifeq ($(shell test -f /proc/version_signature && lsb_release -si
>> 2>/dev/null),Ubuntu)
>> +ifeq ($(shell lsb_release -si 2>/dev/null),Ubuntu)
>> MODULE_CFLAGS += -DUBUNTU_RELEASE_CODE=$(shell lsb_release -sr |
Ping?
(Also including Stephen, Patrice and Pawel which has had comments on an
earlier iteration of this patch).
// Simon
On 2015-08-20 08:51, Simon Kagstrom wrote:
> /proc/version_signature is the version for the host machine, but in
> e.g., chroots, this does not necessarily match that DPDK is
Ping?
// Simon
On 2015-10-20 15:20, Simon Kagstrom wrote:
> The tx_rate unit is Mbps.
>
> Gleaned from the ixgbe implementation, the 82599 datasheet and the use
> in test-pmd.
>
> Signed-off-by: Simon Kagstrom
> ---
> lib/librte_ether/rte_ethdev.h | 2 +-
> 1 file changed, 1 insertion(+), 1
Ping?
(CC:ing Stephen Hemminger as well)
// Simon
On 2015-10-28 10:56, Simon Kagstrom wrote:
> Otherwise mbufs will leak when the port is destroyed. The
> rte_sched_port_qbase() and rte_sched_port_qsize() functions are used
> in free now, so move them up.
>
> Signed-off-by: Simon Kagstrom
>
Hi Liu!
I think this is a really, really great addition!
On 2015-10-29 16:19, Liu, Yong wrote:
> Currently the patch testing only run unit test and basic function test on
> this platform.
> It can make sure that new patch doesn't break original code and functions.
> Due to coverage limitation,
Hi!
What is the unit of the tx_rate parameter to the
rte_eth_set_queue_rate_limit function? It's documented as
/**
* Set the rate limitation for a queue on an Ethernet device.
*
* @param port_id
* The port identifier of the Ethernet device.
* @param queue_idx
* The queue id.
* @param
On 2015-10-13 18:36, Mcnamara, John wrote:
>
> * More sample apps
>
> - Some more examples of using secondary processes.
One thing I would appreciate is more basic samples for the more advanced
functionality. For example, the qos_sched example is (in my opimion)
quite hard to follow since it
On 2015-10-16 15:39, Dumitrescu, Cristian wrote:
>> port->qsize_add[12] = port->qsize_add[11] + port->qsize[2];
>> port->qsize_add[13] = port->qsize_add[12] + port->qsize[3];
>> port->qsize_add[14] = port->qsize_add[13] + port->qsize[3];
>> port->qsize_add[15] =
Hi!
I'm investigating DPDK support for pacing output streams and trying to
understand the QoS framework. However, I quickly found some instances of
unsafe array accesses. E.g., the rte_sched_port_config_qsize function
looks like this:
static void
rte_sched_port_config_qsize(struct
On 2015-10-13 14:45, Thomas Monjalon wrote:
> 2015-10-13 14:39, Simon K?gstr?m:
>> Two of the patches (this one included) I have outstanding are build fixes
>> for use in our build environment, so it would be nice to them upstreamed.
>
> Waiting for integration of your patches, maybe you have
On 2015-10-13 14:26, Olivier MATZ wrote:
> Sorry for not having answered before.
Thanks for looking at it now though!
>> This is one of three outstanding DPDK patches I have which hasn't seen
>> any activitiy in a while. Is there a list of pending applies somewhere
>> to monitor activity?
>
>
On 2015-09-24 10:36, Thomas Monjalon wrote:
> 2015-09-23 23:56, St Leger, Jim:
>> This call is aimed to get more open dialogue in the community.
>
> I wonder how a call can "get more open dialogue"?
> Because of being "live", a lot of people cannot attend at this time.
> A call is also a place
On 2015-09-08 01:21, Ananyev, Konstantin wrote:
>>
>> Thanks. I got it wrong anyway, what I wanted was to be able to handle
>> the day when nb_segs changes to a 16-bit number, but then it should
>> really be
>>
>> ... >= 1 << (sizeof(head->nb_segs) * 8)
>>
>> anyway. I'll fix that and also add a
On 2015-09-07 14:32, Ananyev, Konstantin wrote:
>> +static inline int rte_pktmbuf_chain(struct rte_mbuf *head, struct rte_mbuf
>> *tail)
>> +{
>> +struct rte_mbuf *cur_tail;
>> +
>> +/* Check for number-of-segments-overflow */
>> +if (head->nb_segs + tail->nb_segs >=
On 2015-09-07 11:35, Olivier MATZ wrote:
>> Wonder why do we need to do that?
>> Probably head mbuf is out of space and want to expand it using
>> pktmbuf_chain()?
>> So in that case seems logical:
>> 1) allocate new mbuf (it's pkt_len will be 0)
>> b) call pktmbuf_chain()
>
> By experience,
On 2015-06-23 12:39, Simon Kagstrom wrote:
> Newer kernels make this unreadable for security reasons for non-roots.
> Running the application will then fill the logs with
>
> rte_mem_virt2phy: cannot open /proc/self/pagemap
>
> messages.
I found a bug with the patch, so please disregard it
On 2015-06-23 09:47, Thomas Monjalon wrote:
> 2015-06-23 08:39, Gonzalez Monroy, Sergio:
>> I guess you could argue that, to always build with debug info then strip
>> it down.
>> You would need another flag to strip debug info for production, or leave
>> it for debugging.
>>
>> In my opinion is
On 2015-06-22 09:44, Gonzalez Monroy, Sergio wrote:
> On 19/06/2015 22:29, Cyril Chemparathy wrote:
>> From: Cyril Chemparathy
>>
>> It is often useful to build with debug enabled, we add a config
>> (CONFIG_RTE_TOOLCHAIN_DEBUG) to do so.
>>
>> +ifeq ($(CONFIG_RTE_TOOLCHAIN_DEBUG),y)
>>
On 2015-06-04 23:27, Chilikin, Andrey wrote:
>> Its not a bad addition, I'm just not sure its worth having to take on the
>> additional API surface to include. I'd be more supportive if you could
>> enhance
>> the function to allow the previously mentioned before/after flexibiilty.
>> Then
On 2015-06-02 05:44, Zhang, Helin wrote:
>> -Original Message-
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Simon Kagstrom
>> Sent: Thursday, May 7, 2015 9:18 PM
>> To: dev at dpdk.org
>> Subject: [dpdk-dev] [PATCH / RFC] kni: Add set_rx_mode callback to handle
>> multicast
On 2015-05-28 12:48, Wodkowski, PawelX wrote:
>>> Please only check if UTS_RELEASE is available on all Ubuntu versions DPDK
>> support.
>>
>> From some digging, it appears it entered the kernel tree in 2006 and
>> moved to include/generated/ in 2009 so I guess that should be fine for
>> DPDK
On 2015-05-28 12:05, Wodkowski, PawelX wrote:
>>>
>>> -UBUNTU_KERNEL_CODE := $(shell cut -d' ' -f2 /proc/version_signature | \
>>> -cut -d'~' -f1 | cut -d- -f1,2 | tr .- $(comma))
>>> +UBUNTU_KERNEL_CODE := $(shell echo `grep UTS_RELEASE
>>>
Stephen, Helin, perhaps you have some comment about this patch?
// Simon
On 2015-05-07 15:17, Simon Kagstrom wrote:
> This is needed to add / remove interfaces in multicast groups via the
> ip tool.
>
> The callback does nothing - the same as the kernel tun.c.
>
> Signed-off-by: Simon Kagstrom
Thanks for the review, Sergio!
On 2015-05-28 09:49, Gonzalez Monroy, Sergio wrote:
>> @@ -325,6 +327,12 @@ rte_reorder_insert(struct rte_reorder_buffer *b,
>> struct rte_mbuf *mbuf)
>> uint32_t offset, position;
>> struct cir_buffer *order_buf = >order_buf;
>> +if
I spot a can of worms to be opened here :-)
On 2015-05-27 22:48, Thomas F Herbert wrote:
> Work Flow and Process:
>
> All patches will be taken from from public submissions to dpdk-dev.org
> scraped from dpdk patchwork. Patches will be applied to the patch-test
> tree and tested against HEAD as
Hi John and David!
On 2015-05-27 09:29, Mcnamara, John wrote:>
> Minor comments.
>
> * Without mem_parsed the () aren't required and the conditional will
fit on one line.
>
> * The section prefix on the first/subject line should be "eal:" and
the commit message/justification could be clearer. It
Hi!
As a well-meaning outsider submitting small patches to DPDK, I'd very
much appreciate help from the community with review and comments. Since
I'm a DPDK newbie, the patches might be incorrect or wrong in some other
way, so I think it's even more important with reviews for people like me.
But
Ping?
// Simon
On 2015-05-07 15:17, Simon Kagstrom wrote:
> This is needed to add / remove interfaces in multicast groups via the
> ip tool.
>
> The callback does nothing - the same as the kernel tun.c.
>
> Signed-off-by: Simon Kagstrom
> ---
> Marked RFC since I'm by no means an expert on
On 2015-05-06 10:12, Panu Matilainen wrote:
> On 05/05/2015 07:43 PM, Wiles, Keith wrote:
>
>> GitHub offers a different set of processes and
>> tools, which we do not have to create. Moving to GitHub is a change
>> for the community and I feel a good change for the better.
>
> Like quite a few
On 2015-05-05 11:00, Olivier MATZ wrote:
> On 05/05/2015 11:00 AM, Olivier Matz wrote:
>> The script relpath.sh return the relative path of the first directory
>> from the second directory. It is used to generate relative symlinks,
>> which can be useful if the build directory is embedded in the
On 2015-05-04 14:48, Olivier MATZ wrote:
> Hi Simon,
>
> On 05/04/2015 02:42 PM, Simon K?gstr?m wrote:
>> Hi!
>>
>> I'm trying to do a out-of-tree build of DPDK 2.0.0 (with make -C and
>> O=), but failing with errors such as
>>
>> In file included from
>>
Hi!
I'm trying to do a out-of-tree build of DPDK 2.0.0 (with make -C and
O=), but failing with errors such as
In file included from
[...]/lib/librte_eal/common/include/rte_eal_memconfig.h:40:0,
[...]
rte_malloc_heap.h:39:26: fatal error: rte_spinlock.h: No such file or
directory
Looking
On 2015-03-23 17:29, Thomas Monjalon wrote:
> 2015-03-20 16:18, Simon K?gstr?m:
>>> - make autotests easier and faster to run for smoke testing
>>> - automated basic testpmd check
>>
>> Code coverage for automated tests can be useful as well.
>>
>> In a way I'm speaking in my own interests
On 2015-03-20 15:51, Thomas Monjalon wrote:
> As we are lazy developers, writing guidelines is not enough. It must be
> coupled with the integration of some tools. Let's work on these ones:
> - make autotests easier and faster to run for smoke testing
> - automated basic testpmd check
On 2015-03-06 11:30, Ananyev, Konstantin wrote:
>
> Hi Simon,
>
>> -Original Message-
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Simon K?gstr?m
>> Sent: Friday, March 06, 2015 8:28 AM
>> To: dev at dpdk.org
>> Subject: Re: [dpdk-dev] [PATCH] headers: typeof -> __typeof__
Ping? Konstantins simpler patch is fine for me, but at least one of
these two would be very nice to have so that modern C++ code can use DPDK.
// Simon
On 2015-03-02 08:55, Simon K?gstr?m wrote:
> On 2015-02-27 17:24, Ananyev, Konstantin wrote:
>> Actually, I wonder wouldn't something like the
51 matches
Mail list logo
