> On May 4, 2020, at 3:59 AM, Neale Ranns via lists.fd.io
> wrote:
>
>
> Hi Chris,
>
> With SAs there are two scenarios to consider for inflight packets
> 1) the SA is unlinked
> 2) the SA is deleted.
>
> We've talked at length about how to deal with 2).
> By 'unlinked' I mean that whatever
Hi Chris,
With SAs there are two scenarios to consider for inflight packets
1) the SA is unlinked
2) the SA is deleted.
We've talked at length about how to deal with 2).
By 'unlinked' I mean that whatever config dictated that an SA be used has now
gone (like tunnel protection or SPD policy).
Hi Neale,
Comments also inline...
Neale Ranns (nranns) writes:
Hi Chris,
Comments inline...
On 15/04/2020 15:14, "Christian Hopps" wrote:
Hi Neale,
I agree that something like 4, is probably the correct approach. I had a side-meeting
with some of the ARM folks (Govind and Honn
Hi Chris,
Comments inline...
On 15/04/2020 15:14, "Christian Hopps" wrote:
Hi Neale,
I agree that something like 4, is probably the correct approach. I had a
side-meeting with some of the ARM folks (Govind and Honnappa), and we thought
using a generation number for the state rather
Perhaps useful noting that our meeting was about a month ago, and had focused
on the similar "4" like approach (albeit using the generation number)
independently as well.
I'd still like to get some more timing information on barrier timings vs
ref-counting though. Are a few clocks for reference
Hi Neale,
I agree that something like 4, is probably the correct approach. I had a
side-meeting with some of the ARM folks (Govind and Honnappa), and we thought
using a generation number for the state rather than just waiting "long-enough"
to recycle it could work. The generation number would b
Hi Chris,
Firstly, apologies for the lengthy delay.
When I say 'state' in the following I'm referring to some object[s] that are
used to forward packets.
I'd classify the possible solution space as:
1) maintain per-packet counters for the state to indicate how many packets
currently refer t
> On Mar 25, 2020, at 1:39 PM, Dave Barach via Lists.Fd.Io
> wrote:
>
> Vlib_main_t *vm->main_loop_count.
>
> One trip around the main loop accounts for all per-worker local graph edges /
> acyclic graph behaviors.
>
> As to the magic number E (not to be confused with e): repeatedly handin
PM
To: Dave Barach (dbarach)
Cc: Christian Hopps ; dmar...@me.com; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] worker barrier state
I'm not clear on what you mean by table add/del, but I can give you the
scenario I'm concerned with.
I have a packet P input and it has some state S assoc
) the underlying data structure.
>
> Dave
>
>
> From: vpp-dev@lists.fd.io On Behalf Of Damjan Marion
> via Lists.Fd.Io
> Sent: Wednesday, March 25, 2020 12:10 PM
> To: Christian Hopps
> Cc: vpp-dev@lists.fd.io
> Subject: Re: [vpp-dev] worker barrier state
>
>
, delete (or pool_put) the
underlying data structure.
Dave
From: vpp-dev@lists.fd.io On Behalf Of Damjan Marion via
Lists.Fd.Io
Sent: Wednesday, March 25, 2020 12:10 PM
To: Christian Hopps
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] worker barrier state
> On 25 Mar 2020, at 16:01, Christ
> On 25 Mar 2020, at 16:01, Christian Hopps wrote:
>
> Is it supposed to be the case that no packets are inflight (*) in the graph
> when the worker barrier is held?
>
> I think perhaps MP unsafe API code is assuming this.
>
> I also think that the frame queues used by handoff code violate t
Is it supposed to be the case that no packets are inflight (*) in the graph
when the worker barrier is held?
I think perhaps MP unsafe API code is assuming this.
I also think that the frame queues used by handoff code violate this assumption.
Can someone with deep VPP knowledge clarify this for
13 matches
Mail list logo
