On Linux and most other systems, network interface index is a 32-bit
integer. Indexes overflowing the 16-bit integer are frequently seen
when used inside a Docker container.
Signed-off-by: Alex Kiselev
---
drivers/net/tap/tap_flow.c | 2 +-
drivers/net/tap/tap_tcmsgs.c | 18
On Linux and most other systems, network interface index is a 32-bit
integer. Indexes overflowing the 16-bit integer are frequently seen
when used inside a Docker container.
Signed-off-by: Alex Kiselev
---
drivers/net/tap/tap_flow.c | 2 +-
drivers/net/tap/tap_tcmsgs.c | 18
rte_lpm6: fix incorrect size of tbl8 group
Fixes: e480688dce6d ("lpm6: add incremental update on delete")
Signed-off-by: Alex Kiselev
---
lib/librte_lpm/rte_lpm6.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/lib/librte_lpm/rte_lpm6.c b/lib/librte_lpm/rte_lp
rte_lpm6: fix incorrect size of tbl8 group
Signed-off-by: Alex Kiselev
---
lib/librte_lpm/rte_lpm6.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/lib/librte_lpm/rte_lpm6.c b/lib/librte_lpm/rte_lpm6.c
index 1047efa8a..f5979fb15 100644
--- a/lib/librte_lpm/rte_lpm6.c
Hi,
>
>
> >
> > As a general remark consider writing all of the tbl entries including
> > tbl8 with atomic_store. Now "lpm->tbl8[j] = new_tbl8_entry;" is looks like
> >
> > 1e9: 44 88 9c 47 40 01 00mov
> > %r11b,0x2000140(%rdi,%rax,2) <-write first byte
> > 1f0: 02
> >
пт, 5 июл. 2019 г. в 13:31, Medvedkin, Vladimir :
>
> Hi Stephen,
>
> On 28/06/2019 16:35, Stephen Hemminger wrote:
> > On Fri, 28 Jun 2019 15:16:30 +0100
> > "Medvedkin, Vladimir" wrote:
> >
> >> Hi Honnappa,
> >>
> >> On 28/06/2019 14:57, Honnappa Nagarahalli wrote:
> Hi all,
>
>
lpm6: add incremental update on delete
rework the delete function and add additional
internal data structures to support incremental
LPM tree update rather than full tree rebuild
Signed-off-by: Alex Kiselev
Acked-by: Bruce Richardson
---
lib/librte_lpm/rte_lpm6.c | 712
lpm6: store rules in hash table for lpm6
Rework the lpm6 rule subsystem and replace
current rules algorithm complexity O(n)
with hashtables which allow dealing with
large (50k) rule sets.
Signed-off-by: Alex Kiselev
Acked-by: Bruce Richardson
---
lib/Makefile | 2 +-
lib
it's easier to keep track of mbufs inside the library.
>
>>> else
>>> mbuf_in_frag_table -= reassembled_mbuf->nb_segs;
>>> mbuf_in_frag_table += dr->cnt - n;
>>> Also, in that case every rte_ip_frag_free_death_row() needs a wrapper c
t; Also, in that case every rte_ip_frag_free_death_row() needs a wrapper code
>> too.
>> n= dr->cnt;
>> rte_ip_frag_free_death_row(..)
>> mbuf_in_frag_table += dr->cnt - n;
> I don't think it is necessary.
> After packet is put in the death-row
librte_lpm: Improve lpm6 performance
Rework the lpm6 rule subsystem and replace
current rules algorithm complexity O(n)
with hashtables which allow dealing with
large (50k) rule sets.
Signed-off-by: Alex Kiselev
---
lib/Makefile | 2 +-
lib/librte_lpm/Makefile| 2 +-
lib
librte_lpm: Improve lpm6 performance
There is no need to rebuild the whole LPM tree
when a rule is deleted. This patch addresses this
issue introducing new delete operation.
Signed-off-by: Alex Kiselev
---
lib/librte_lpm/rte_lpm6.c | 712 ++
1 file
> On Wed, 11 Jul 2018 20:53:46 +0300
> Alex Kiselev wrote:
>> librte_lpm: Improve lpm6 performance
>> Rework the lpm6 rule subsystem and replace
>> current rules algorithm complexity O(n)
>> with hashtables which allow dealing with
>> large (50k) rule sets
Здравствуйте, Alex.
Вы писали 16 июля 2018 г., 18:36:25:
>> On Mon, 16 Jul 2018 11:05:27 +0300
>> Alex Kiselev wrote:
>>> librte_lpm: Improve lpm6 performance
>>> Rework the lpm6 rule subsystem and replace
>>> current rules algorithm complexity O(n)
> On Mon, 16 Jul 2018 11:05:27 +0300
> Alex Kiselev wrote:
>> librte_lpm: Improve lpm6 performance
>> Rework the lpm6 rule subsystem and replace
>> current rules algorithm complexity O(n)
>> with hashtables which allow dealing with
>> large (50k) rule s
> Also. Please run checkpatch shell script on your patches. For example, there
> should be blank line between declarations and code.
fixed in v5
--
Alex
librte_lpm: Improve lpm6 performance
Rework the lpm6 rule subsystem and replace
current rules algorithm complexity O(n)
with hashtables which allow dealing with
large (50k) rule sets.
Signed-off-by: Alex Kiselev
---
lib/Makefile | 2 +-
lib/librte_lpm/meson.build | 1 +
lib
librte_lpm: Improve lpm6 performance
There is no need to rebuild the whole LPM tree
when a rule is deleted. This patch addresses this
issue introducing new delete operation.
Signed-off-by: Alex Kiselev
---
lib/librte_lpm/rte_lpm6.c | 712 ++
1 file
> On Wed, 11 Jul 2018 20:53:46 +0300
> Alex Kiselev wrote:
>> librte_lpm: Improve lpm6 performance
...
>>
>> /* LPM Tables. */
>> - struct rte_lpm6_rule *rules_tbl; /**< LPM rules. */
>> + struct rte_mempool *rules_pool; /**< LPM
librte_lpm: Improve lpm6 performance
Rework the lpm6 rule subsystem and replace
current rules algorithm complexity O(n)
with hashtables which allow dealing with
large (50k) rule sets.
Signed-off-by: Alex Kiselev
---
lib/Makefile | 2 +-
lib/librte_lpm/meson.build | 1 +
lib
librte_lpm: Improve lpm6 performance
There is no need to rebuild the whole LPM tree
when a rule is deleted. This patch addresses this
issue introducing new delete operation.
Signed-off-by: Alex Kiselev
---
lib/librte_lpm/rte_lpm6.c | 698 ++
1 file
There is no need to rebuild the whole LPM tree
when a rule is deleted. This patch addresses this
issue introducing new delete operation.
Signed-off-by: Alex Kiselev
---
lib/librte_lpm/rte_lpm6.c | 698 ++
1 file changed, 583 insertions(+), 115
librte_lpm: Improve lpm6 performance
Rework the lpm6 rule subsystem and replace
current rules algorithm complexity O(n)
with hashtables which allow dealing with
large (50k) rule sets.
Signed-off-by: Alex Kiselev
---
lib/Makefile | 2 +-
lib/librte_lpm/meson.build | 1 +
lib
>> + int ret = rte_hash_lookup_data(lpm->rules_tbl, (void *) &rule_key,
>> + (void **) &rule);
>> + if (ret >= 0) {
>> + /* delete the rule */
>> + rte_hash_del_key(lpm->rules_tbl, (void *) &rule_key);
>> + lpm->used_rules--;
>> +
Please see inline replies
> On Mon, Jul 02, 2018 at 07:42:11PM +0300, Alex Kiselev wrote:
>> There are two major problems with the library:
>> first, there is no need to rebuild the whole LPM tree
>> when a rule is deleted and second, due to the current
>> rules al
_ID_ANY, &config);
TEST_LPM_ASSERT(lpm3 == NULL);
> On Mon, Jul 02, 2018 at 07:42:11PM +0300, Alex Kiselev wrote:
>> There are two major problems with the library:
>> first, there is no need to rebuild the whole LPM tree
>> when a rule is deleted and second, due t
e two issues.
Signed-off-by: Alex Kiselev
---
lib/librte_lpm/rte_lpm6.c | 1073 ++---
1 file changed, 816 insertions(+), 257 deletions(-)
diff --git a/lib/librte_lpm/rte_lpm6.c b/lib/librte_lpm/rte_lpm6.c
index 149677eb1..438db0831 100644
--- a/lib/librt
cnt - n;
Also, in that case every rte_ip_frag_free_death_row() needs a wrapper code too.
n= dr->cnt;
rte_ip_frag_free_death_row(..)
mbuf_in_frag_table += dr->cnt - n;
I think my approach is simplier.
> Konstantin
>> Signed-off-by: Alex Kiselev
>> ---
>> lib/librte_ip
e two issues.
Signed-off-by: Alex Kiselev
---
lib/librte_lpm/rte_lpm6.c | 1072 ++---
lib/librte_lpm/rte_lpm6.h |1 +
2 files changed, 816 insertions(+), 257 deletions(-)
diff --git a/lib/librte_lpm/rte_lpm6.c b/lib/librte_lpm/rte_lpm6.c
index 1496
> Please see comments below.
From: Matan Azrad
>> +/*
>> + * Remove additional MAC addresses from the slave */ int
>> +slave_remove_mac_addresses(struct rte_eth_dev *bonded_eth_dev,
>> + uint16_t slave_port_id)
>> +{
>> + int i, ret = 0;
>> + struct ether_addr *mac_addr;
>>
add functions to add/remove MAC addresses
Signed-off-by: Alex Kiselev
---
drivers/net/bonding/rte_eth_bond_api.c | 12 ++-
drivers/net/bonding/rte_eth_bond_pmd.c | 131 -
drivers/net/bonding/rte_eth_bond_private.h | 8 ++
3 files changed, 146 insertions
Hi Matan.
> Hi Alex
> Please see comments below.
>> +
>> + ret = rte_eth_dev_mac_addr_add(slave_port_id, mac_addr, 0);
>> + if (ret < 0) {
>> + /* rollback */
>> + for (i--; i > 0; i--)
>> +
> In case of failure in the first mac a
> On Mon, 18 Jun 2018 15:27:16 +0300
> Alex Kiselev wrote:
>> +/*
>> + * Remove additional MAC addresses from the slave
>> + */
>> +int
>> +slave_remove_mac_addresses(struct rte_eth_dev *bonded_eth_dev,
>> + uint16_t slave_port_id)
> From: Chas Williams
>> On Mon, Jun 18, 2018 at 2:58 PM Stephen Hemminger <
>> step...@networkplumber.org> wrote:
>> > On Mon, 18 Jun 2018 15:27:16 +0300
>> > Alex Kiselev wrote:
>> >
>> > > +static const struct ether_addr null
add functions to add/remove MAC addresses
Signed-off-by: Alex Kiselev
---
drivers/net/bonding/rte_eth_bond_api.c | 12 ++-
drivers/net/bonding/rte_eth_bond_pmd.c | 127 -
drivers/net/bonding/rte_eth_bond_private.h | 8 ++
3 files changed, 142 insertions
add functions to add/remove MAC addresses
Signed-off-by: Alex Kiselev
---
drivers/net/bonding/rte_eth_bond_api.c | 8 +-
drivers/net/bonding/rte_eth_bond_pmd.c | 123 -
drivers/net/bonding/rte_eth_bond_private.h | 8 ++
3 files changed, 134 insertions
a PMD but also an application.
On Fri, May 25, 2018 at 12:21 PM, Alex Kiselev wrote:
add functions to add/remove MAC addresses
Signed-off-by: Alex Kiselev
---
drivers/net/bonding/rte_eth_bond_pmd.c | 76 +++---
1 file changed, 71 insertions(+), 5 deletions(-)
diff
the number of mbufs holded int the fragmentation
table. This patch allows to keep track of the number of mbufs
holded in the fragmentation table.
Signed-off-by: Alex Kiselev
---
lib/librte_ip_frag/ip_frag_common.h| 16 +---
lib/librte_ip_frag/ip_frag_internal.c | 16
A fragmented packets is supposed to live no longer than max_cycles,
but the lib deletes an expired packet only occasionally when it scans
a bucket to find an empty slot while adding a new packet.
Therefore a fragment might sit in the table forever.
Signed-off-by: Alex Kiselev
---
lib
Hi Konstantin.
> Hi Alex,
>> -Original Message-
>> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Alex Kiselev
>> Sent: Wednesday, May 16, 2018 12:04 PM
>> To: dev@dpdk.org; Burakov, Anatoly
>> Subject: [dpdk-dev] [PATCH 1/2] librte_ip_frag: a
Hi Konstantin.
>> -Original Message-
>> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Alex Kiselev
>> Sent: Wednesday, May 16, 2018 12:04 PM
>> To: dev@dpdk.org; Burakov, Anatoly
>> Subject: [dpdk-dev] [PATCH 2/2] librte_ip_frag: add mbu
add functions to add/remove MAC addresses
Signed-off-by: Alex Kiselev
---
drivers/net/bonding/rte_eth_bond_pmd.c | 76 +++---
1 file changed, 71 insertions(+), 5 deletions(-)
diff --git a/drivers/net/bonding/rte_eth_bond_pmd.c
b/drivers/net/bonding
to the fragmentations table since it already
contains to many of them. Currently there is no way to
determine the number of mbufs holded int the fragmentation
table. This patch allows to keep track of the number of mbufs
holded in the fragmentation table.
Signed-off-by: Alex Kiselev
---
lib
while adding a new packet.
Therefore a fragment might sit in the table forever.
Signed-off-by: Alex Kiselev
---
lib/librte_ip_frag/ip_frag_common.h| 18
lib/librte_ip_frag/ip_frag_internal.c | 18
lib/librte_ip_frag/rte_ip_frag.h | 19
39 100644
--- a/lib/librte_ip_frag/rte_ipv6_reassembly.c
+++ b/lib/librte_ip_frag/rte_ipv6_reassembly.c
@@ -213,7 +213,7 @@ rte_ipv6_frag_reassemble_packet(struct rte_ip_frag_tbl *tbl,
/* process the fragmented packet. */
- mb = ip_frag_process(fp, dr, mb, ip_ofs, ip_len,
+ mb = ip_frag_process(tbl, fp, dr, mb, ip_ofs, ip_len,
MORE_FRAGS(frag_hdr->frag_data));
ip_frag_inuse(tbl, fp);
--
Alex Kiselev
kisele...@gmail.com
I am sorry. I should've posted to the user list of couse.
My mistake.
2018-02-13 22:37 GMT+03:00 Alex Kiselev :
> Hi.
>
> I've been wondering should I use a release/acquire memory barrier pair
> in order to be sure that the other thread will see the fully/corrected
> in
Hi.
I've been wondering should I use a release/acquire memory barrier pair
in order to be sure that the other thread will see the fully/corrected
initialized object
passed to it via a dpdk ring or ring itself is a kind of barrier?
Let's say I have a pseudo code:
Thread1:
obj = alloc();
...
obj i
ays and then one of the tx queues stops transmitting packets. Last time
> tx queue number 2 (of total 5) failed on both slave ports at the same time.
>
> What could cause that behavior?
>
> Thank you.
>
> --
> Alex Kiselev
--
--
Kiselev Alexander
48 matches
Mail list logo
