|
Chris Luke
I would like to see a tidy way to pull in these plugin projects into a VPP build with minimal fuss, including building against a dev tree of VPP without having
to install it first – otherwise I can see the edit-build-test cycle when you need to make even minor changes in both a plugin and VPP becoming a burden.
It’s probably a pretty simple shell script, or an environment variable that “make build” uses to find other stuff to go build after it’s done with VPP. Or something.
Chris.
toggle quoted message
Show quoted text
From: vpp-dev-bounces@... [mailto:vpp-dev-bounces@...]
On Behalf Of Keith Burns
Sent: Sunday, April 24, 2016 20:08
To: Zhou, Danny <danny.zhou@...>; nsh_sfc-dev@...; vpp-dev <vpp-dev@...>
Subject: Re: [vpp-dev] [nsh_sfc-dev] Moving NSH code to NSH_SFC repo from VPP
Danny,
The goal would be that there would be no functionality change. There is an NSH project though with its own repo and committers, which is where the code should live.
As such, it has to be a plugin. To keep it as is, I believe, would mean it would have to live in the VPP repo. Ie be part of the VPP project, not the NSH project.
Hey Keith,
With respect to the patch to remove the NSH support from VPP, I would prefer to keep it as it is because
it could be easily extended to support two other usages:
1)
NSH proxy (as a NSH gateway doing NSH and local circuit conversion). BTW, prototype is ready with initial performance data, we can discuss it and architectural diagrams in
the meeting tomorrow.
2)
NSH-aware SF (recognize NSH and decrement SI when pushing NSH tunneling packet to SFF)
I am fine if the plugin could support above two usages after removing the NSH support from VPP.
-Danny
From:
nsh_sfc-dev-bounces@... [mailto:nsh_sfc-dev-bounces@...]
On Behalf Of Keith Burns
Sent: Sunday, April 24, 2016 11:40 PM
To: nsh_sfc-dev@...; vpp-dev <vpp-dev@...>
Subject: [nsh_sfc-dev] Moving NSH code to NSH_SFC repo from VPP
Folks,
I have a design I would like to pursue to move the work I already did in VPP over to NSH_sfc and make that project a plugin.
Note this doesn't have to be a "final" or absolute design for how this works but I do feel the NSH work I've already started is unfinished based on the limited functionality it
was targeting (simplistic SFF and classifier PoC), so it's important to me personally to complete that.
Should that be merged (note that this will be two patches, one for VPP removing the code and another for NSH_SFC to add to a different repo) we would need to coordinate across projects.
Thats not a big deal, and I'll be sure to link both patches but note any changes suggested to one will potentially mean changes to the other.
I expect this to be ready before midweek. I would have loved to have had it ready for the NSH meeting tomorrow but perhaps we can review some diagrams I have as part of the agenda
(agenda link coming) instead.
|
|
|
Dave Barach (dbarach) <dbarach@...>
If you install the usual set of .debs - regardless of where they come from - simply “make; make install” the set of plugin(s) you want to work
with.
If you’re working on both vpp and plugin(s), “make; make install” the plugins, “make PLATFORM=vpp TAG=vpp_debug vpp-install”,
and execute [or more likely, gdb] “.../build-root/install-vpp_debug-native/vpp/bin/vpp”.
My own workflow in such cases is to install .debs once, start vpp once to ensure hugetlb page setup, general sanity, etc. Stop
vpp. Then debug the “install-vpp_debug-native” executable. Due to rpath manipulation, it’s not necessary to install new .debs to work on library code.
toggle quoted message
Show quoted text
From: vpp-dev-bounces@... [mailto:vpp-dev-bounces@...]
On Behalf Of Luke, Chris
Sent: Sunday, April 24, 2016 8:18 PM
To: Keith Burns <alagalah@...>; Zhou, Danny <danny.zhou@...>; nsh_sfc-dev@...; vpp-dev <vpp-dev@...>
Subject: Re: [vpp-dev] [nsh_sfc-dev] Moving NSH code to NSH_SFC repo from VPP
I would like to see a tidy way to pull in these plugin projects into a VPP build with minimal fuss, including building against a dev tree of VPP without having
to install it first – otherwise I can see the edit-build-test cycle when you need to make even minor changes in both a plugin and VPP becoming a burden.
It’s probably a pretty simple shell script, or an environment variable that “make build” uses to find other stuff to go build after it’s done with VPP. Or something.
Chris.
Danny,
The goal would be that there would be no functionality change. There is an NSH project though with its own repo and committers, which is where the code should live.
As such, it has to be a plugin. To keep it as is, I believe, would mean it would have to live in the VPP repo. Ie be part of the VPP project, not the NSH project.
Hey Keith,
With respect to the patch to remove the NSH support from VPP, I would prefer to keep it as it is because
it could be easily extended to support two other usages:
1)
NSH proxy (as a NSH gateway doing NSH and local circuit conversion). BTW, prototype is ready with initial performance data, we can discuss it and architectural diagrams in
the meeting tomorrow.
2)
NSH-aware SF (recognize NSH and decrement SI when pushing NSH tunneling packet to SFF)
I am fine if the plugin could support above two usages after removing the NSH support from VPP.
-Danny
From:
nsh_sfc-dev-bounces@... [mailto:nsh_sfc-dev-bounces@...]
On Behalf Of Keith Burns
Sent: Sunday, April 24, 2016 11:40 PM
To: nsh_sfc-dev@...; vpp-dev <vpp-dev@...>
Subject: [nsh_sfc-dev] Moving NSH code to NSH_SFC repo from VPP
Folks,
I have a design I would like to pursue to move the work I already did in VPP over to NSH_sfc and make that project a plugin.
Note this doesn't have to be a "final" or absolute design for how this works but I do feel the NSH work I've already started is unfinished based on the limited functionality it
was targeting (simplistic SFF and classifier PoC), so it's important to me personally to complete that.
Should that be merged (note that this will be two patches, one for VPP removing the code and another for NSH_SFC to add to a different repo) we would need to coordinate across projects.
Thats not a big deal, and I'll be sure to link both patches but note any changes suggested to one will potentially mean changes to the other.
I expect this to be ready before midweek. I would have loved to have had it ready for the NSH meeting tomorrow but perhaps we can review some diagrams I have as part of the agenda
(agenda link coming) instead.
|
|
|
Edward Warnicke
And for folks looking to install debs/rpms from binaries (for example, folks just working on plugin code):
We keep our apt/yum repos fresh merge by merge :)
Ed
On Mon, Apr 25, 2016 at 6:53 AM, Dave Barach (dbarach) <dbarach@...> wrote:
If you install the usual set of .debs - regardless of where they come from - simply “make; make install” the set of plugin(s) you want to work
with.
If you’re working on both vpp and plugin(s), “make; make install” the plugins, “make PLATFORM=vpp TAG=vpp_debug vpp-install”,
and execute [or more likely, gdb] “.../build-root/install-vpp_debug-native/vpp/bin/vpp”.
My own workflow in such cases is to install .debs once, start vpp once to ensure hugetlb page setup, general sanity, etc. Stop
vpp. Then debug the “install-vpp_debug-native” executable. Due to rpath manipulation, it’s not necessary to install new .debs to work on library code.
I would like to see a tidy way to pull in these plugin projects into a VPP build with minimal fuss, including building against a dev tree of VPP without having
to install it first – otherwise I can see the edit-build-test cycle when you need to make even minor changes in both a plugin and VPP becoming a burden.
It’s probably a pretty simple shell script, or an environment variable that “make build” uses to find other stuff to go build after it’s done with VPP. Or something.
Chris.
Danny,
The goal would be that there would be no functionality change. There is an NSH project though with its own repo and committers, which is where the code should live.
As such, it has to be a plugin. To keep it as is, I believe, would mean it would have to live in the VPP repo. Ie be part of the VPP project, not the NSH project.
Hey Keith,
With respect to the patch to remove the NSH support from VPP, I would prefer to keep it as it is because
it could be easily extended to support two other usages:
1)
NSH proxy (as a NSH gateway doing NSH and local circuit conversion). BTW, prototype is ready with initial performance data, we can discuss it and architectural diagrams in
the meeting tomorrow.
2)
NSH-aware SF (recognize NSH and decrement SI when pushing NSH tunneling packet to SFF)
I am fine if the plugin could support above two usages after removing the NSH support from VPP.
-Danny
From:
nsh_sfc-dev-bounces@... [mailto:nsh_sfc-dev-bounces@...]
On Behalf Of Keith Burns
Sent: Sunday, April 24, 2016 11:40 PM
To: nsh_sfc-dev@...; vpp-dev <vpp-dev@...>
Subject: [nsh_sfc-dev] Moving NSH code to NSH_SFC repo from VPP
Folks,
I have a design I would like to pursue to move the work I already did in VPP over to NSH_sfc and make that project a plugin.
Note this doesn't have to be a "final" or absolute design for how this works but I do feel the NSH work I've already started is unfinished based on the limited functionality it
was targeting (simplistic SFF and classifier PoC), so it's important to me personally to complete that.
Should that be merged (note that this will be two patches, one for VPP removing the code and another for NSH_SFC to add to a different repo) we would need to coordinate across projects.
Thats not a big deal, and I'll be sure to link both patches but note any changes suggested to one will potentially mean changes to the other.
I expect this to be ready before midweek. I would have loved to have had it ready for the NSH meeting tomorrow but perhaps we can review some diagrams I have as part of the agenda
(agenda link coming) instead.
_______________________________________________
vpp-dev mailing list
vpp-dev@...
https://lists.fd.io/mailman/listinfo/vpp-dev
|
|
|
