subject:"\[vpp\-dev\] Feedback on a tool\: vppcfg"

Re: [vpp-dev] Feedback on a tool: vppcfg

2022-04-04 Thread Luca Muscariello via lists.fd.io

Hi Pim

This is very helpful.
I'll give it a try ASAP.

Dave's proposal to incubate thi project in FDio as a subproject makes sense
and I would be interested to follow up on that.


On Sat, Apr 2, 2022 at 5:18 PM Pim van Pelt  wrote:

> Hoi colleagues,
>
> I know there exist several smaller and larger scale VPP configuration
> harnesses out there, some more complex and feature complete than others. I
> wanted to share my work on an approach based on a YAML configuration with
> strict syntax and semantic validation, and a path planner that brings the
> dataplane from any configuration state safely to any other
> configuration state, as defined by these YAML files.
>
> A bit of a storyline on the validator:
> https://ipng.ch/s/articles/2022/03/27/vppcfg-1.html
> A bit of background on the DAG path planner:
> https://ipng.ch/s/articles/2022/04/02/vppcfg-2.html
> Code with tests on https://github.com/pimvanpelt/vppcfg
>

The architecture looks similar to neplan + systemd-networkd.
I did not check the code yet in detail so I may be wrong.

Thanks for sharing
Luca




>
> The config and planner supports interfaces, bondethernets, vxlan tunnels,
> l2xc, bridgedomains and, quelle surprise, linux-cp configurations of all
> sorts. If anybody feels like giving it a spin, I'd certainly appreciate
> feedback and if you can manage to create two configuration states that the
> planner cannot reconcile, I'd love to hear about those too.
>
> For now, the path planner works by reading the API configuration state
> exactly once (at startup), and then it figures out the CLI calls to print
> without needing to consult VPP again. This is super useful as it’s a
> non-intrusive way to inspect the changes before applying them, and it’s a
> property I’d like to carry forward. However, I don’t necessarily think that
> emitting the CLI statements is the best user experience, it’s more for the
> purposes of analysis that they can be useful. What I really want to do is
> emit API calls after the plan is created and reviewed/approved, directly
> reprogramming the VPP dataplane. However, the VPP API set needed to do this
> is not 100% baked yet. For example, I observed crashes when tinkering with
> BVIs and Loopbacks (see my thread from last week, thanks for the response
> Neale), and fixed a few obvious errors in the Linux CP API (gerrit) but
> there are still a few more issues to work through before I can set the next
> step with vppcfg.
>




>
> If this tool proves to be useful to others, I'm happy to upstream it to
> extras/ somewhere.
>
> --
> Pim van Pelt 
> PBVP1-RIPE - http://www.ipng.nl/
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21197): https://lists.fd.io/g/vpp-dev/message/21197
Mute This Topic: https://lists.fd.io/mt/90202690/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Feedback on a tool: vppcfg

2022-04-04 Thread Eyle Brinkhuis

Hoi Pim,

This solves a challenge we are having in our infrastructure. Will give this a 
spin shortly!

—
Eyle

> On 3 Apr 2022, at 18:26, Pim van Pelt  wrote:
> 
> Hoi,
> 
> That's so much more enthusiasm than I had anticipated, thank you very much 
> for your kind and encouraging words! I've spent some time writing a starting 
> set of documentation.
> User Guide: https://github.com/pimvanpelt/vppcfg/blob/main/docs/user-guide.md 
> <https://github.com/pimvanpelt/vppcfg/blob/main/docs/user-guide.md>
> Config Guide: 
> https://github.com/pimvanpelt/vppcfg/blob/main/docs/config-guide.md 
> <https://github.com/pimvanpelt/vppcfg/blob/main/docs/config-guide.md>
> 
> The config guide mentions a few caveats, nothing major, but just a few 
> considerations in case we do want to elevate this and use it more broadly 
> than just my basement ISP. While I wait around a bit for community feedback 
> on its use,  I've cleaned up the code a bit, so that it can serve as a 
> standalone compiled binary now:
> usage: vppcfg [-h] [-d] [-q] [-f] {check,dump,plan,apply} ...
> 
> positional arguments:
>   {check,dump,plan,apply}
> check   check given YAML config for validity (no VPP)
> dumpdump current running VPP configuration (VPP readonly)
> planplan changes from current VPP dataplane to target 
> config (VPP readonly)
> apply   apply changes from current VPP dataplane to target 
> config
> 
> optional arguments:
>   -h, --helpshow this help message and exit
>   -d, --debug   enable debug logging, default False
>   -q, --quiet   be quiet (only warnings/errors), default False
>   -f, --force   force progress despite warnings, default False
> 
> Please see vppcfg  -h   for per-command arguments
> 
> groet,
> Pim
> 
> On Sun, Apr 3, 2022 at 8:46 AM Jerome Tollet (jtollet)  <mailto:jtol...@cisco.com>> wrote:
> Hi Pim,
> 
> Over the past few years, we had many discussions about how best can VPP be 
> configured by end users.
> 
> What is really nice with your proposal is that it’s pragmatic and  simple. 
> Actually much more simple than the Netconf/yang (remember Honeycomb…) and 
> probably cover many use cases.
> 
> I’ve not yet tried it but will certainly do it soon.
> 
> Thanks !
> 
> Jerome
> 
>  
> 
> De : vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io>  <mailto:vpp-dev@lists.fd.io>> de la part de Pim van Pelt  <mailto:p...@ipng.nl>>
> Date : samedi, 2 avril 2022 à 17:18
> À : vpp-dev mailto:vpp-dev@lists.fd.io>>
> Objet : [vpp-dev] Feedback on a tool: vppcfg
> 
> Hoi colleagues,
> 
>  
> 
> I know there exist several smaller and larger scale VPP configuration 
> harnesses out there, some more complex and feature complete than others. I 
> wanted to share my work on an approach based on a YAML configuration with 
> strict syntax and semantic validation, and a path planner that brings the 
> dataplane from any configuration state safely to any other configuration 
> state, as defined by these YAML files.
> 
>  
> 
> A bit of a storyline on the validator: 
> https://ipng.ch/s/articles/2022/03/27/vppcfg-1.html 
> <https://ipng.ch/s/articles/2022/03/27/vppcfg-1.html>
> A bit of background on the DAG path planner: 
> https://ipng.ch/s/articles/2022/04/02/vppcfg-2.html 
> <https://ipng.ch/s/articles/2022/04/02/vppcfg-2.html>
> Code with tests on https://github.com/pimvanpelt/vppcfg 
> <https://github.com/pimvanpelt/vppcfg>
>  
> 
> The config and planner supports interfaces, bondethernets, vxlan tunnels, 
> l2xc, bridgedomains and, quelle surprise, linux-cp configurations of all 
> sorts. If anybody feels like giving it a spin, I'd certainly appreciate 
> feedback and if you can manage to create two configuration states that the 
> planner cannot reconcile, I'd love to hear about those too.
> 
>  
> 
> For now, the path planner works by reading the API configuration state 
> exactly once (at startup), and then it figures out the CLI calls to print 
> without needing to consult VPP again. This is super useful as it’s a 
> non-intrusive way to inspect the changes before applying them, and it’s a 
> property I’d like to carry forward. However, I don’t necessarily think that 
> emitting the CLI statements is the best user experience, it’s more for the 
> purposes of analysis that they can be useful. What I really want to do is 
> emit API calls after the plan is created and reviewed/approved, directly 
> reprogramming the VPP dataplane. However, the VPP API set needed to do this 
> is not 100% baked yet. For example, I observed crashes when tinkering

Re: [vpp-dev] Feedback on a tool: vppcfg

2022-04-03 Thread Pim van Pelt

Hoi,

That's so much more enthusiasm than I had anticipated, thank you very much
for your kind and encouraging words! I've spent some time writing a
starting set of documentation.
User Guide:
https://github.com/pimvanpelt/vppcfg/blob/main/docs/user-guide.md
Config Guide:
https://github.com/pimvanpelt/vppcfg/blob/main/docs/config-guide.md

The config guide mentions a few caveats, nothing major, but just a few
considerations in case we do want to elevate this and use it more broadly
than just my basement ISP. While I wait around a bit for community feedback
on its use,  I've cleaned up the code a bit, so that it can serve as a
standalone compiled binary now:
usage: vppcfg [-h] [-d] [-q] [-f] {check,dump,plan,apply} ...

positional arguments:
  {check,dump,plan,apply}
check   check given YAML config for validity (no VPP)
dumpdump current running VPP configuration (VPP
readonly)
planplan changes from current VPP dataplane to target
config (VPP readonly)
apply   apply changes from current VPP dataplane to target
config

optional arguments:
  -h, --helpshow this help message and exit
  -d, --debug   enable debug logging, default False
  -q, --quiet   be quiet (only warnings/errors), default False
  -f, --force   force progress despite warnings, default False

Please see vppcfg  -h   for per-command arguments

groet,
Pim

On Sun, Apr 3, 2022 at 8:46 AM Jerome Tollet (jtollet) 
wrote:

> Hi Pim,
>
> Over the past few years, we had many discussions about how best can VPP be
> configured by end users.
>
> What is really nice with your proposal is that it’s pragmatic and  simple.
> Actually much more simple than the Netconf/yang (remember Honeycomb…) and
> probably cover many use cases.
>
> I’ve not yet tried it but will certainly do it soon.
>
> Thanks !
>
> Jerome
>
>
>
> *De : *vpp-dev@lists.fd.io  de la part de Pim van
> Pelt 
> *Date : *samedi, 2 avril 2022 à 17:18
> *À : *vpp-dev 
> *Objet : *[vpp-dev] Feedback on a tool: vppcfg
>
> Hoi colleagues,
>
>
>
> I know there exist several smaller and larger scale VPP configuration
> harnesses out there, some more complex and feature complete than others. I
> wanted to share my work on an approach based on a YAML configuration with
> strict syntax and semantic validation, and a path planner that brings the
> dataplane from any configuration state safely to any other
> configuration state, as defined by these YAML files.
>
>
>
> A bit of a storyline on the validator:
> https://ipng.ch/s/articles/2022/03/27/vppcfg-1.html
>
> A bit of background on the DAG path planner:
> https://ipng.ch/s/articles/2022/04/02/vppcfg-2.html
>
> Code with tests on https://github.com/pimvanpelt/vppcfg
>
>
>
> The config and planner supports interfaces, bondethernets, vxlan tunnels,
> l2xc, bridgedomains and, quelle surprise, linux-cp configurations of all
> sorts. If anybody feels like giving it a spin, I'd certainly appreciate
> feedback and if you can manage to create two configuration states that the
> planner cannot reconcile, I'd love to hear about those too.
>
>
>
> For now, the path planner works by reading the API configuration state
> exactly once (at startup), and then it figures out the CLI calls to print
> without needing to consult VPP again. This is super useful as it’s a
> non-intrusive way to inspect the changes before applying them, and it’s a
> property I’d like to carry forward. However, I don’t necessarily think that
> emitting the CLI statements is the best user experience, it’s more for the
> purposes of analysis that they can be useful. What I really want to do is
> emit API calls after the plan is created and reviewed/approved, directly
> reprogramming the VPP dataplane. However, the VPP API set needed to do this
> is not 100% baked yet. For example, I observed crashes when tinkering with
> BVIs and Loopbacks (see my thread from last week, thanks for the response
> Neale), and fixed a few obvious errors in the Linux CP API (gerrit) but
> there are still a few more issues to work through before I can set the next
> step with vppcfg.
>
> If this tool proves to be useful to others, I'm happy to upstream it to
> extras/ somewhere.
>
>
>
> --
>
> Pim van Pelt 
> PBVP1-RIPE - http://www.ipng.nl/
>


-- 
Pim van Pelt 
PBVP1-RIPE - http://www.ipng.nl/

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21187): https://lists.fd.io/g/vpp-dev/message/21187
Mute This Topic: https://lists.fd.io/mt/90202690/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Feedback on a tool: vppcfg

2022-04-03 Thread Jerome Tollet via lists.fd.io

Hi Pim,
Over the past few years, we had many discussions about how best can VPP be 
configured by end users.
What is really nice with your proposal is that it’s pragmatic and  simple. 
Actually much more simple than the Netconf/yang (remember Honeycomb…) and 
probably cover many use cases.
I’ve not yet tried it but will certainly do it soon.
Thanks !
Jerome

De : vpp-dev@lists.fd.io  de la part de Pim van Pelt 

Date : samedi, 2 avril 2022 à 17:18
À : vpp-dev 
Objet : [vpp-dev] Feedback on a tool: vppcfg
Hoi colleagues,

I know there exist several smaller and larger scale VPP configuration harnesses 
out there, some more complex and feature complete than others. I wanted to 
share my work on an approach based on a YAML configuration with strict syntax 
and semantic validation, and a path planner that brings the dataplane from any 
configuration state safely to any other configuration state, as defined by 
these YAML files.

A bit of a storyline on the validator: 
https://ipng.ch/s/articles/2022/03/27/vppcfg-1.html
A bit of background on the DAG path planner: 
https://ipng.ch/s/articles/2022/04/02/vppcfg-2.html
Code with tests on https://github.com/pimvanpelt/vppcfg

The config and planner supports interfaces, bondethernets, vxlan tunnels, l2xc, 
bridgedomains and, quelle surprise, linux-cp configurations of all sorts. If 
anybody feels like giving it a spin, I'd certainly appreciate feedback and if 
you can manage to create two configuration states that the planner cannot 
reconcile, I'd love to hear about those too.

For now, the path planner works by reading the API configuration state exactly 
once (at startup), and then it figures out the CLI calls to print without 
needing to consult VPP again. This is super useful as it’s a non-intrusive way 
to inspect the changes before applying them, and it’s a property I’d like to 
carry forward. However, I don’t necessarily think that emitting the CLI 
statements is the best user experience, it’s more for the purposes of analysis 
that they can be useful. What I really want to do is emit API calls after the 
plan is created and reviewed/approved, directly reprogramming the VPP 
dataplane. However, the VPP API set needed to do this is not 100% baked yet. 
For example, I observed crashes when tinkering with BVIs and Loopbacks (see my 
thread from last week, thanks for the response Neale), and fixed a few obvious 
errors in the Linux CP API (gerrit) but there are still a few more issues to 
work through before I can set the next step with vppcfg.
If this tool proves to be useful to others, I'm happy to upstream it to extras/ 
somewhere.

--
Pim van Pelt mailto:p...@ipng.nl>>
PBVP1-RIPE - http://www.ipng.nl/

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21186): https://lists.fd.io/g/vpp-dev/message/21186
Mute This Topic: https://lists.fd.io/mt/90202690/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Feedback on a tool: vppcfg

2022-04-02 Thread Dave Wallace


Hi Pim,

This is most excellent!  Thank you for sharing your work.

I also have only taken a quick pass through the information you posted, 
but have been thinking about tackling a YAML or JSON based configuration 
format to help simplify the unit testing environment and make use case 
test automation more accessible.


From a FD.io community perspective, your work could readily be set up 
as a sub-project which would be extremely beneficial were it to be 
adopted as a tool to be utilized in the test pipeline in addition to 
other downstream VPP consumers.


I will give a test drive this week and provide some feedback to you. I'm 
very interested in helping out with this effort.


In case you are not aware, Ole introduced JSON formatted API output and 
vat2 which translates JSON api files into VPP api calls.  I have used 
this feature to capture 'make test' testcase configurations and replay 
them to VPP using vat2.  This experiment is part of the 'make test' 
framework refactoring that I am engaged in to separate Scapy packet 
stream processing (pcap input file generation and pcap output file 
verification) from the 'make test' python framework.  I haven't looked 
at your implementation closely at this point, so you may in fact already 
be using this.  If so, please excuse my ignorance. :)


There is also a gap in VPP control plane interfaces between the Debug 
CLI and VPP-API. As you mention in your write-up, the debug CLI is NOT 
intended to be used as the primary control plane interface.


The original control plane design patter by Dave Barach was to split 
feature configuration into parallel CLI/API parsing/message validation 
stages, each of which would call the same feature config function. This 
allowed Dave to rapidly prototype the configuration interface using the 
debug CLI and subsequently add the VPP-API with minimal effort.


Unfortunately this architecture has not been utilized universally as VPP 
features have been added. This has led to inconsistency between debug 
CLI commands and the VPP-API.  While it is understandable that there are 
debug configuration attributes that are not appropriate for the 
production API, I think that it would be great to make a pass through 
the feature set to align them more closely and to promote the sharing of 
common configuration code in VPP features between the Debug CLI and VPP-API.


In any case, enough of my ranting -- thanks again for your contributions 
to VPP & the FD.io community!

-daw-


On 4/2/2022 2:21 PM, Florin Coras wrote:

Hi Pim,

Definitely cool! Haven’t had a chance to go through all of it but the 
fact that some binary api calls crash vpp is something we should fix.


It feels like vppcfg could also be used for extensive vpp api/cli/cfg 
testing.


My quick 0.02$

Regards,
Florin


On Apr 2, 2022, at 8:17 AM, Pim van Pelt  wrote:

Hoi colleagues,

I know there exist several smaller and larger scale VPP configuration 
harnesses out there, some more complex and feature complete than 
others. I wanted to share my work on an approach based on a YAML 
configuration with strict syntax and semantic validation, and a path 
planner that brings the dataplane from any configuration state safely 
to any other configuration state, as defined by these YAML files.


A bit of a storyline on the validator: 
https://ipng.ch/s/articles/2022/03/27/vppcfg-1.html
A bit of background on the DAG path planner: 
https://ipng.ch/s/articles/2022/04/02/vppcfg-2.html

Code with tests on https://github.com/pimvanpelt/vppcfg

The config and planner supports interfaces, bondethernets, vxlan 
tunnels, l2xc, bridgedomains and, quelle surprise, linux-cp 
configurations of all sorts. If anybody feels like giving it a spin, 
I'd certainly appreciate feedback and if you can manage to create two 
configuration states that the planner cannot reconcile, I'd love to 
hear about those too.


For now, the path planner works by reading the API configuration 
state exactly once (at startup), and then it figures out the CLI 
calls to print without needing to consult VPP again. This is super 
useful as it’s a non-intrusive way to inspect the changes before 
applying them, and it’s a property I’d like to carry forward. 
However, I don’t necessarily think that emitting the CLI statements 
is the best user experience, it’s more for the purposes of analysis 
that they can be useful. What I really want to do is emit API calls 
after the plan is created and reviewed/approved, directly 
reprogramming the VPP dataplane. However, the VPP API set needed to 
do this is not 100% baked yet. For example, I observed crashes when 
tinkering with BVIs and Loopbacks (see my thread from last week, 
thanks for the response Neale), and fixed a few obvious errors in the 
Linux CP API (gerrit) but there are still a few more issues to work 
through before I can set the next step with vppcfg.


If this tool proves to be useful to others, I'm happy to upstream it 
to extras/ somewhere.


--
Pim van Pelt

Re: [vpp-dev] Feedback on a tool: vppcfg

2022-04-02 Thread Florin Coras

Hi Pim, 

Definitely cool! Haven’t had a chance to go through all of it but the fact that 
some binary api calls crash vpp is something we should fix. 

It feels like vppcfg could also be used for extensive vpp api/cli/cfg testing. 

My quick 0.02$

Regards,
Florin

> On Apr 2, 2022, at 8:17 AM, Pim van Pelt  wrote:
> 
> Hoi colleagues,
> 
> I know there exist several smaller and larger scale VPP configuration 
> harnesses out there, some more complex and feature complete than others. I 
> wanted to share my work on an approach based on a YAML configuration with 
> strict syntax and semantic validation, and a path planner that brings the 
> dataplane from any configuration state safely to any other configuration 
> state, as defined by these YAML files.
> 
> A bit of a storyline on the validator: 
> https://ipng.ch/s/articles/2022/03/27/vppcfg-1.html 
> 
> A bit of background on the DAG path planner: 
> https://ipng.ch/s/articles/2022/04/02/vppcfg-2.html 
> 
> Code with tests on https://github.com/pimvanpelt/vppcfg 
> 
> 
> The config and planner supports interfaces, bondethernets, vxlan tunnels, 
> l2xc, bridgedomains and, quelle surprise, linux-cp configurations of all 
> sorts. If anybody feels like giving it a spin, I'd certainly appreciate 
> feedback and if you can manage to create two configuration states that the 
> planner cannot reconcile, I'd love to hear about those too.
> 
> For now, the path planner works by reading the API configuration state 
> exactly once (at startup), and then it figures out the CLI calls to print 
> without needing to consult VPP again. This is super useful as it’s a 
> non-intrusive way to inspect the changes before applying them, and it’s a 
> property I’d like to carry forward. However, I don’t necessarily think that 
> emitting the CLI statements is the best user experience, it’s more for the 
> purposes of analysis that they can be useful. What I really want to do is 
> emit API calls after the plan is created and reviewed/approved, directly 
> reprogramming the VPP dataplane. However, the VPP API set needed to do this 
> is not 100% baked yet. For example, I observed crashes when tinkering with 
> BVIs and Loopbacks (see my thread from last week, thanks for the response 
> Neale), and fixed a few obvious errors in the Linux CP API (gerrit) but there 
> are still a few more issues to work through before I can set the next step 
> with vppcfg.
> 
> If this tool proves to be useful to others, I'm happy to upstream it to 
> extras/ somewhere.
> 
> -- 
> Pim van Pelt mailto:p...@ipng.nl>> 
> PBVP1-RIPE - http://www.ipng.nl/ 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21184): https://lists.fd.io/g/vpp-dev/message/21184
Mute This Topic: https://lists.fd.io/mt/90202690/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] Feedback on a tool: vppcfg

2022-04-02 Thread Pim van Pelt

Hoi colleagues,

I know there exist several smaller and larger scale VPP configuration
harnesses out there, some more complex and feature complete than others. I
wanted to share my work on an approach based on a YAML configuration with
strict syntax and semantic validation, and a path planner that brings the
dataplane from any configuration state safely to any other
configuration state, as defined by these YAML files.

A bit of a storyline on the validator:
https://ipng.ch/s/articles/2022/03/27/vppcfg-1.html
A bit of background on the DAG path planner:
https://ipng.ch/s/articles/2022/04/02/vppcfg-2.html
Code with tests on https://github.com/pimvanpelt/vppcfg

The config and planner supports interfaces, bondethernets, vxlan tunnels,
l2xc, bridgedomains and, quelle surprise, linux-cp configurations of all
sorts. If anybody feels like giving it a spin, I'd certainly appreciate
feedback and if you can manage to create two configuration states that the
planner cannot reconcile, I'd love to hear about those too.

For now, the path planner works by reading the API configuration state
exactly once (at startup), and then it figures out the CLI calls to print
without needing to consult VPP again. This is super useful as it’s a
non-intrusive way to inspect the changes before applying them, and it’s a
property I’d like to carry forward. However, I don’t necessarily think that
emitting the CLI statements is the best user experience, it’s more for the
purposes of analysis that they can be useful. What I really want to do is
emit API calls after the plan is created and reviewed/approved, directly
reprogramming the VPP dataplane. However, the VPP API set needed to do this
is not 100% baked yet. For example, I observed crashes when tinkering with
BVIs and Loopbacks (see my thread from last week, thanks for the response
Neale), and fixed a few obvious errors in the Linux CP API (gerrit) but
there are still a few more issues to work through before I can set the next
step with vppcfg.

If this tool proves to be useful to others, I'm happy to upstream it to
extras/ somewhere.

-- 
Pim van Pelt 
PBVP1-RIPE - http://www.ipng.nl/

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21183): https://lists.fd.io/g/vpp-dev/message/21183
Mute This Topic: https://lists.fd.io/mt/90202690/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Feedback on a tool: vppcfg

Re: [vpp-dev] Feedback on a tool: vppcfg

Re: [vpp-dev] Feedback on a tool: vppcfg

Re: [vpp-dev] Feedback on a tool: vppcfg

Re: [vpp-dev] Feedback on a tool: vppcfg

Re: [vpp-dev] Feedback on a tool: vppcfg

[vpp-dev] Feedback on a tool: vppcfg

7 matches

Site Navigation

Mail list logo

Footer information