Hello,
I am now fully allocated to monitor the issue and find most appropriate
solution as long term fix.
There were few issues identified.
1) Race condition on Intel x700 series card being tracked in separate mail
([csit-dev] [vpp-dev] VPP Device jobs randomly failing) and being solved with
Damjan,
Thanks!
Best wishes,
Hemant
From: vpp-dev@lists.fd.io On Behalf Of Damjan Marion via
lists.fd.io
Sent: Wednesday, January 20, 2021 10:34 AM
To: hem...@mnkcg.com
Cc: bga...@cisco.com; ne...@graphiant.com; ayour...@gmail.com;
vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] cl
Please note that we also have fixed pool implementation which may be used if
you want to prevent pool resizing…..
Another option is to make your entries cacheline aligned, and then convert
pointer to heap offset shifted right for LOG2_CACHELINE_SIZE.
That will give you working solution for HEA
Hi Ben,
Great, thanks for the pool info! I am all set. I will close the JIRA issue
and also the code review.
Best wishes,
Hemant
-Original Message-
From: Benoit Ganne (bganne)
Sent: Wednesday, January 20, 2021 9:47 AM
To: hem...@mnkcg.com; ne...@graphiant.com; ayour...@gmail.com
Cc:
> No, a u64 suffices. See how the u64 works with a bihash for any value, not
> just pkt_filter4_0_value, in the code example given below.
Ok thanks. So you use the u64 to store a pointer to your structure allocated on
the heap.
The usual way to do this in VPP instead is to allocate your structure
Hi Andreas,
Great question! I am ccing to the list as well.
I don’t think the VPP-UPG uses VPP classifier API, does it?
I used the following recursive grep in the root directory for VPP-UPG and
didn’t incur any hit. These are the API for using the VPP classifier.
grep -R macip_
Hi Neale,
Thanks for the reply. I agree on 2). Tracking opaque’s validity is work I
will have to look into.
Cheers,
Hemant
From: Neale Ranns
Sent: Wednesday, January 20, 2021 4:18 AM
To: hem...@mnkcg.com; ayour...@gmail.com
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] classif
No, a u64 suffices. See how the u64 works with a bihash for any value, not
just pkt_filter4_0_value, in the code example given below.
struct pkt_filter4_0_value val = {}, *value;
val.action = permit4;
val.u.permit4.abits = 130;
val.u.permit4.ig_strip = 0;
val.u.permit4.outer_desc =
> A github link is included in the JIRA issue to articulate the use case,
> https://jira.fd.io/browse/VPP-1967
> The github link has a value for a classifier entry shown:
> https://github.com/FDio/vpp/pull/33
> The value is a value used in a 5G UPF.
Is the 64-bits value you refer to the "struct pk
A github link is included in the JIRA issue to articulate the use case,
https://jira.fd.io/browse/VPP-1967
The github link has a value for a classifier entry shown:
https://github.com/FDio/vpp/pull/33
The value is a value used in a 5G UPF.
The classifier entry's metadata cannot support su
Maybe the 1st question should be what is your usecase here? What is the 64-bits
used for? It would be better to rely on the already-existing u32 opaque_index
instead.
If you really need a u64 value, you can always get away with it by using a pool
of u64 values indexed by opaque_index, and look u
Hi Hemant,
I’ll be a little more direct 😊 you can’t expand the size of opaque. The blast
radius of such a change is just too large.
Your alternative choices are: 1) use oqaque2, 2) overlay your ‘value’ field in
the union in opaque. The latter is preferable since you won’t incur the cost of
load
Hi Anurag,
Inline.
> On Jan 19, 2021, at 11:54 PM, anurag.bhumc...@hotmail.com wrote:
>
> Hi All,
>
> I have few queries related to VPP Host TCP stack:
> 1. Can we use only VPP TCP stack(L4 layer) only and disable L2/L3. If not
> what is its advantage of TLDK or similar stacks.
Not sure I fo
13 matches
Mail list logo
