Leela,
Is your question is why isn't the client part of the VPP application itself?
If so, the answer is to separate the control plane from the data plane
utilizing a fast, efficient shared-memory interface.
VPP is a highly tuned, high performance packet manipulation/forwarding
user-space app
To add to what Jim said.
> I don't think I totally get it.
> My question was to ask why does anyone need to write 'shared-memory' access
> to call the corresponding binary API for each and every feature set that one
> is interested in.
> If there is a direct client library available, then it wou
Leela,
I’m not entirely sure I understand your question, but I’ll try to answer.
1) It’s an open source project. If you have a vision to improve it, you can
propose same and submit patches.
2) there are implementations of an external API. The FD.io Honeycomb project
implements NETCONF/RES
I don't think I totally get it.
My question was to ask why does anyone need to write 'shared-memory' access to
call the corresponding binary API for each and every feature set that one is
interested in.
If there is a direct client library available, then it would be much easy to
call the direct
**EXTERNAL**] Re: [vpp-dev] VPP client: test_client vs VAT
Leela,
VAT is an integral part of the Continuous Integration testing infrastructure so
that is NOT appropriate to extend for your application. However, it does offer
a good set of example code on how to implement a VPP client using
