Re: [vpp-dev] ip4 length > l2 length with memif + TRex
Hi, I have debugged the issue mentioned in the original message further and found a couple of bugs in the DPDK memif driver. There's a bug in mbuf chaining code [1] and also another bug in memif_stats_get() function [2] for which I made downstream PRs for TRex [3][4]. This is not in any way a VPP problem, but I hope if someone trying to use TRex or another DPDK app with VPP and memifs stumbles upon this message it might be of some help (as far as I know, TRex is used in VPP CSIT to some degree). [1] https://bugs.dpdk.org/show_bug.cgi?id=729 [2] https://bugs.dpdk.org/show_bug.cgi?id=734 [3] https://github.com/cisco-system-traffic-generator/trex-core/pull/723 [4] https://github.com/cisco-system-traffic-generator/trex-core/pull/728 On Wed, Apr 21, 2021 at 5:08 PM Ivan Shvedunov via lists.fd.io wrote: > Hello, > > I've been struggling with the following issue (observed with VPP 21.01): > when trying any of ASTF TRex profiles with VPP, I get multiple errors: > "ip4 length > l2 length". > These don't happen with each packet but rather with some of them. It looks > like the TCP payload is truncated down to 600 bytes for some reason, while > looking at the TRex simulation, it should be 1448 bytes. > I have collected a snippet from dispatch trace dissected by Wireshark > and other info here: > https://gist.github.com/ivan4th/e0130dac619f91a6bb8e7987550c2466 > I'm not really sure this is VPP and not a TRex issue, especially given > that it's only seen in ASTF mode of TRex, but I'm asking it here b/c > (1) TRex is used for CSIT > (2) There's an old open ticket for a similar CSIT problem: > https://jira.fd.io/browse/VPP-1676 > Not sure if it was resolved somehow already. > > Passing --tso-disable --lro-disable --checksum-offload-disable flags to > TRex doesn't change anything. > > If there's no known solution for this issue, I'll dig into it myself, > but I'd like to ask if maybe it was already solved by someone. Thanks! > > -- > Ivan Shvedunov > ;; My GPG fingerprint is: 2E61 0748 8E12 BB1A 5AB9 F7D0 613E C0F8 0BC5 > 2807 > > > > -- Ivan Shvedunov ;; My GPG fingerprint is: 2E61 0748 8E12 BB1A 5AB9 F7D0 613E C0F8 0BC5 2807 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#19566): https://lists.fd.io/g/vpp-dev/message/19566 Mute This Topic: https://lists.fd.io/mt/83533776/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] Question on Averaging Window Support #vpp #vpp-dev
Hi All,
We are trying to implement the averaging window associated with QoS flows
in VPP - 21.06
We found that HQoS implementation in dpdk plugin, has tc_period
calculation, but deprecated from vpp.
The following policer was configured
configure policer name policer_avg type 1r2c cir 450 cb 512 rate kbps
conform-action mark-and-transmit CS4 exceed-action drop
Following traces were added and observed with one ingress packet
DBGvpp# At vnet_police_packet time -> 80082589943
packet_length = packet_length << policer->scale -> 56320
n_periods = time - policer->last_update_time -> 80082589943
policer->last_update_time = time -> 80082589943
current_tokens=policer->current_bucket + n_periods *
policer->cir_tokens_per_period -> 131418151536463
current_tokens = policer->current_limit -> 262144
extended_tokens = policer->extended_bucket + n_periods *
policer->cir_tokens_per_period -> 131415530096463
extended_tokens = policer->extended_limit -> 0
IF current_tokens >= packet_length 262144 -> 56320
policer->current_bucket = current_tokens - packet_length -> 2621383680
policer->extended_bucket = extended_tokens - packet_length -> 4294910976
>From the above added traces, our understanding is
"n_periods is the variable used for averaging window." Is our understanding
correct.
Could you please let us know the usage of last_update_time in policer_t.
Below code snippet is seen in HQoS, however deprecated in latest VPP.
@param tc_period - enforcement period for rates (measured in milliseconds)
define sw_interface_set_dpdk_hqos_subport {
u32 client_index;
u32 context;
u32 sw_if_index;
u32 subport;
u32 tb_rate;
u32 tb_size;
u32 tc_rate[4];
u32 tc_period;
};
Does tc_period computes the averaging window?
If so, what is the equivalent to tc_period as in HQoS?
Kindly let us know if Averaging window concept is handled in current code,
or share your view in handling it in VPP.
Thanks and regards,
Athilakshmi S
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19565): https://lists.fd.io/g/vpp-dev/message/19565
Mute This Topic: https://lists.fd.io/mt/83532794/21656
Mute #vpp:https://lists.fd.io/g/vpp-dev/mutehashtag/vpp
Mute #vpp-dev:https://lists.fd.io/g/vpp-dev/mutehashtag/vpp-dev
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] "unix-cli-local" node corruption in node_by_name hash #vpp #vpp-dev
Ack, thanks... See https://gerrit.fd.io/r/c/vpp/+/32688; merged in
master/latest. Cherry-picked into stable/2106, should cherry-pick into older
releases if needed.
D.
From: vpp-dev@lists.fd.io On Behalf Of sontu mazumdar
Sent: Sunday, June 13, 2021 1:35 PM
To: Dave Barach
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] "unix-cli-local" node corruption in node_by_name hash
#vpp #vpp-dev
Thanks for the patch Dave.
With this I am not seeing the corruption
issue of node hash key in node_by_name hash.
Regards,
Sontu
On Sat, 12 Jun, 2021, 11:09 AM sontu mazumdar, mailto:sont...@gmail.com> > wrote:
Thanks Dave.
I will try with your suggested code changes and will share the result.
Regards,
Sontu
On Fri, 11 Jun, 2021, 9:34 PM Dave Barach, mailto:v...@barachs.net> > wrote:
Please try these diffs and report results.
diff --git a/src/vlib/unix/cli.c b/src/vlib/unix/cli.c
index 6c9886725..ce29e0723 100644
--- a/src/vlib/unix/cli.c
+++ b/src/vlib/unix/cli.c
@@ -2863,6 +2863,7 @@ unix_cli_file_add (unix_cli_main_t * cm, char *name, int
fd)
{
unix_main_t *um = &unix_main;
clib_file_main_t *fm = &file_main;
+ vlib_node_main_t *nm = &vlib_get_main()->node_main;
unix_cli_file_t *cf;
clib_file_t template = { 0 };
vlib_main_t *vm = um->vlib_main;
@@ -2896,10 +2897,12 @@ unix_cli_file_add (unix_cli_main_t * cm, char *name,
int fd)
old_name = n->name;
n->name = (u8 *) name;
}
+ ASSERT(old_name);
+ hash_unset (nm->node_by_name, old_name);
+ hash_set (nm->node_by_name, name, n->index);
vec_free (old_name);
vlib_node_set_state (vm, n->index, VLIB_NODE_STATE_POLLING);
-
_vec_len (cm->unused_cli_process_node_indices) = l - 1;
}
else
From: vpp-dev@lists.fd.io mailto:vpp-dev@lists.fd.io> > On Behalf Of sontu mazumdar
Sent: Friday, June 11, 2021 11:34 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] "unix-cli-local" node corruption in node_by_name hash #vpp
#vpp-dev
Hi,
I observe that in node_by_name hash we store a node with name
"unix-cli-local:0" and node index 720 (not sure the purpose of the node).
The node name is stored as key in the node_by_name hash.
But later at some time when I print the node_by_name hash's each entry I see
the key of node i.e the node name is printing some junk value (I figured it out
via checking it against the node index).
When I looked at code in unix_cli_file_add(), below we are first time adding
the node with name "unix-cli-local:0".
static vlib_node_registration_t r = {
.function = unix_cli_process,
.type = VLIB_NODE_TYPE_PROCESS,
.process_log2_n_stack_bytes = 18,
};
r.name = name;
vlib_worker_thread_barrier_sync (vm);
vlib_register_node (vm, &r);
vec_free (name);
n = vlib_get_node (vm, r.index);
vlib_worker_thread_node_runtime_update ();
vlib_worker_thread_barrier_release (vm);
Later it again calls unix_cli_file_add(), there we pass a different name
"unix-cli-local:1".
In this case we are overwriting the already existing node name from
"unix-cli-local:0" to "unix-cli-local:1".
for (i = 0; i < vec_len (vlib_mains); i++)
{
this_vlib_main = vlib_mains[i];
if (this_vlib_main == 0)
continue;
n = vlib_get_node (this_vlib_main,
cm->unused_cli_process_node_indices[l - 1]);
old_name = n->name; <<<
n->name = (u8 *) name; <<<
}
vec_free (old_name); <<
But the node name is already present in node_by_name hash as a key and there we
haven't updated it instead we have deleted the old name.
This is resulting in printing some corrupted node name for the above node in
node_by_name hash, which I think can sometimes results in VPP crash also as the
hash key points to some freed memory.
Regards,
Sontu
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19564): https://lists.fd.io/g/vpp-dev/message/19564
Mute This Topic: https://lists.fd.io/mt/83471274/21656
Mute #vpp:https://lists.fd.io/g/vpp-dev/mutehashtag/vpp
Mute #vpp-dev:https://lists.fd.io/g/vpp-dev/mutehashtag/vpp-dev
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
