Hi Ravin,
I would suggest two things:
1. In your application you should maintain an association between
strongswan’s client and the tunnel you create in VPP for it. Then, since the
routes are associated with the client they can easily be matched to the tunnel.
You’ll need this sort of asso
Ravin,
Due to the RX and TX actions that need to be performed on an SA in an ‘atomic’
fashion, each SA is bound to a single worker thread. The trhread chosen is the
one that first sees a packet for that SA. When subsequent packets arrive on a
different thread they need to be transferred to the
I received a private message indicating that one solution was to just wait
"long enough" for the packets to drain. This is the method I'm going to go with
as it's simple (albeit not as deterministic as some marking/callback scheme :)
For my case I think I can wait ridiculously long for "long en
Hi Chris,
Adding an IS_INBOUND flag could be non-backward compatible if not setting the
INBOUND flag on an SA and then using it in an inbound context resulted in an
error being returned to the user. so existing clients would be obligated to set
this new flag. If that’s not the case, and client
From: on behalf of Christian Hopps
Date: Tuesday 25 February 2020 at 22:09
To: Andrew 👽 Yourtchenko
Cc: Christian Hopps , "Dave Barach (dbarach)"
, vpp-dev
Subject: Re: [vpp-dev] Can I submit some API changes for 19.08, et al. release
branches?
> On Feb 25, 2020, at 3:44 PM, Andrew 👽 You
Hi Chris,
All of the APIs that result in the removal of an SA are not marked as MP safe.
This means that the worker threads are paused at the ‘barrier’ as the API is
handled. Worker threads reach the barrier once they complete the frame they are
working on. So there are no packets in flight whe
> Adding a new API into an existing file will still change the CRC on the
> plugin/module
Looking into a .api.json file, I see "crc" only for messages,
but the whole file also ends with a "vl_api_version" value.
> if we are aiming for binary compatibility
Crc values guard against backward-incom
*Ping/ICMP communication between two peers is not working when using ipv6 link
local address*
The VPP version is 19.01.2 and vppsb router plugin used: Platform is
Linux-Debian.
1st Device: Linux: root@rad:/# ip addr show vpp2 10: vpp2:
mtu 1500 qdisc fq_codel state UP group
default qlen 1000
Coverity run failed today.
Current number of outstanding issues are 6
Newly detected: 0
Eliminated: 0
More details can be found at
https://scan.coverity.com/projects/fd-io-vpp/view_defects
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#15588): ht
[Edited Message Follows]
[Reason: Ping/ICMP communication between two peers is not working when using
ipv6 link local address The VPP version is 19.01.2 and vppsb router plugin
used: Platform is Linux-Debian.]
*Ping/ICMP communication between two peers is not working when using ipv6 link
local
[Edited Message Follows]
*Ping/ICMP communication between two peers is not working when using ipv6 link
local address*
The VPP version is 19.01.2 and vppsb router plugin used: Platform is
Linux-Debian.
*1st Device:*
>
> Linux:
> root@ewn:/# ip addr show vpp2
> 10: vpp2: mtu 1500 qdisc fq_code
> On Feb 27, 2020, at 6:26 AM, Neale Ranns (nranns) wrote:
>
>
> Hi Chris,
>
> Adding an IS_INBOUND flag could be non-backward compatible if not setting the
> INBOUND flag on an SA and then using it in an inbound context resulted in an
> error being returned to the user. so existing clients wo
> On Feb 27, 2020, at 6:26 AM, Neale Ranns (nranns) wrote:
>
>
>
> From: on behalf of Christian Hopps
> Date: Tuesday 25 February 2020 at 22:09
> To: Andrew 👽 Yourtchenko
> Cc: Christian Hopps , "Dave Barach (dbarach)"
> , vpp-dev
> Subject: Re: [vpp-dev] Can I submit some API changes
From: on behalf of Christian Hopps
Date: Thursday 27 February 2020 at 15:16
To: "Neale Ranns (nranns)"
Cc: Christian Hopps , Andrew 👽 Yourtchenko
, "Dave Barach (dbarach)" , vpp-dev
Subject: Re: [vpp-dev] Can I submit some API changes for 19.08, et al. release
branches?
[snip]
>
> In my c
> On Feb 27, 2020, at 9:41 AM, Neale Ranns via Lists.Fd.Io
> wrote:
>
>
>
> From: on behalf of Christian Hopps
> Date: Thursday 27 February 2020 at 15:16
> To: "Neale Ranns (nranns)"
> Cc: Christian Hopps , Andrew 👽 Yourtchenko
> , "Dave Barach (dbarach)" , vpp-dev
>
> Subject: Re: [vpp-
Hello,
This announcement may be of interest to you:
http://lists.openstack.org/pipermail/openstack-discuss/2020-February/012877.html
Jerome
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#15593): https://lists.fd.io/g/vpp-dev/message/15593
Mute Thi
Hi Chris,
There is a design philosophy against sending notifications to agents about
information that comes from agents. This is in contrast to notifications to
agents about events that occur in the data-plane, like DHCP lease, new ARP/ND,
learned L2 addresses, etc.
/neale
From: on behalf o
I think there are similar issues in bi-hash (i.e. the entry could be deleted
from control plane while the data plane threads are doing the lookup).
Thanks,
Honnappa
From: vpp-dev@lists.fd.io On Behalf Of Christian Hopps
via Lists.Fd.Io
Sent: Thursday, February 27, 2020 5:09 AM
To: vpp-dev
Cc:
> On Feb 27, 2020, at 11:45 AM, Neale Ranns (nranns) wrote:
>
>
> Hi Chris,
>
> There is a design philosophy against sending notifications to agents about
> information that comes from agents. This is in contrast to notifications to
> agents about events that occur in the data-plane, like DHC
Unless I misunderstand something, the usual way we deal with that is the worker
barrier as mentioned by Neale.
API calls and CLI commands are executed under this barrier unless marked as
mp_safe (which is off by default).
When the worker barrier is requested by the main thread, all worker thread
Update: CSIT-2001.09 maintenance report has been published:
https://docs.fd.io/csit/rls2001/report/
Changes from last week version include:
Added VPP performance test data into Detailed Results per testbed types:
- 2n-clx (Xeon Cascadelake): IPv4, IPv6, L2.
- 2n-dnv (Atom Den
> On Feb 27, 2020, at 6:35 AM, Neale Ranns via Lists.Fd.Io
> wrote:
>
> Hi Chris,
>
> All of the APIs that result in the removal of an SA are not marked as MP
> safe. This means that the worker threads are paused at the ‘barrier’ as the
> API is handled. Worker threads reach the barrier once
Hi ALL,
I found memfd use normal memory rather than hugepage memory. But
clib_mem_vm_ext_alloc can support hugepage memory now. Can hugepage memory
improve memfd performance ?
Regards,
Hanlin
发自网易邮箱大师-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Onlin
>
> Unless I misunderstand something, the usual way we deal with that is the
> worker barrier as mentioned by Neale.
>
> API calls and CLI commands are executed under this barrier unless marked as
> mp_safe (which is off by default).
> When the worker barrier is requested by the main thread, al
24 matches
Mail list logo
