Re: [vpp-dev] Supported distributions.
> We are mixing today 2 different things: packaging for specific distro and > making sure that code can work with specific build/runtime dependencies. Good point. So basically maintaining something like https://www.kernel.org/doc/html/latest/process/changes.html#current-minimal-requirements ? > Result of that is that we have debian-9 verify job which does not use > debian-9 provided compiler and cmake so it brings zero value. Hmm I am not sure I follow here, if I look at a recent job https://jenkins.fd.io/job/vpp-verify-master-debian9-x86_64/464/consoleFull I see this: [...] 21:27:19 g++ 4:6.3.0-4 21:27:19 g++-6 6.3.0-18+deb9u1 21:27:19 gcc 4:6.3.0-4 21:27:19 gcc-6 6.3.0-18+deb9u1 21:27:19 gcc-6-base:amd646.3.0-18+deb9u1 [...] 21:27:39 Configuring vpp in /w/workspace/vpp-verify-master-debian9-x86_64/build-root/build-vpp-native/vpp 21:27:39 -- The C compiler identification is GNU 6.3.0 [...] So I think we are using the default gcc? Best ben -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#18090): https://lists.fd.io/g/vpp-dev/message/18090 Mute This Topic: https://lists.fd.io/mt/78344343/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] Jenkins jobs UNSTABLE due to failure to upload logs to nexus.fd.io
Folks, IT-21051 was resolved by Vanessa's ci-management patch [0] while [nearly] simultaneously two patches [1] [2] from Andrew Y were deployed which remove the artifact publishing from the VPP CI jobs. These changes were subsequently reverted [3]. Operation of VPP CI jobs has been restored and I have done a 'recheck' on all gerrit changes which previously failed due to the UNSTABLE job completion status. Unfortunately, there is a new issue caused by hitting the Docker Hub Pull limit [4] which is causing job allocations to fail and the jenkins build queue to back up. I have opened a new LF Help Desk Ticket [4], sent an email to the TSC, and will bring this up in tomorrow's TSC meeting to get it resolved. There also appears to be a similar issue with the vpp-csit-verify-device-master-1n-skx job which has jobs failing due to the inability to start containers. Thank you for your patience during this outage and thanks to Vanessa & the entire LF-IT team who worked on identifying the fix to the log upload issue. Also a big thank you to Andrew Yourtchenko for his assistance in pushing ci-management patches and Vratko for ci-management patch reviews. -daw- [0] https://gerrit.fd.io/r/c/ci-management/+/29986 [1] https://gerrit.fd.io/r/c/ci-management/+/29985 [2] https://gerrit.fd.io/r/c/ci-management/+/29987 [3] https://gerrit.fd.io/r/c/ci-management/+/29988 [4] https://jira.linuxfoundation.org/plugins/servlet/theme/portal/2/IT-21063 On 11/17/2020 12:38 PM, Dave Wallace via lists.fd.io wrote: Folks, There is an issue with CI jobs being marked as UNSTABLE due to the failure to upload log files to nexus.fd.io. This is causing the CI job pipeline to be stalled due to checkstyle job not succeeding. I have opened a case with LF-IT: https://jira.linuxfoundation.org/plugins/servlet/theme/portal/2/IT-21051 Thanks, -daw- -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#18089): https://lists.fd.io/g/vpp-dev/message/18089 Mute This Topic: https://lists.fd.io/mt/78321469/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [EXTERNAL] Re: [vpp-dev] vppctl fails from within the application (system cmd returns 256)
Hi Ben, Chris,
thanks for helping debug strace, i was also suspecting the socket return 0
as fd that will cause issue, but root cause for this seemed to be in my
application that had logging functionality - tracing the logs from
different threads to different file streams. when my application starts,
the trace gets initialized first and then application tries to
process/apply vpp config. as a test, i just reversed the order of
initialization of that and let the other threads (that use VCL Tx/Rx)
initialize first. (vpp interface config is before VCL threads). That seemed
to solve the problem.
My application has 1 Rx thread for receiving pkts from source, process
them, and send out using 'n' TX threads that can run in parallel... the
destination ip address of the packet can vary, so each of the Tx threads,
have to maintain a 'vppcom_session' for that ip address (connected udp
socket). i can try to use vppcom_session_sendto --> for multiple
destination ip addresses, and see how it performs/or work fine with N Tx
threads. another alternative is to use memif for each Tx threads.
-Aniket
On Wed, Nov 18, 2020 at 3:38 AM Benoit Ganne (bganne)
wrote:
> Indeed, stdin seems to be closed and vppctl is not written with that in
> mind, just check
> https://git.fd.io/vpp/tree/src/vpp/app/vppctl.c#n223 or
> https://git.fd.io/vpp/tree/src/vpp/app/vppctl.c#n267 for examples... If
> you have s->fd == STDIN_FILENO (as it seems to be the case here) things are
> going to break.
>
> If I understand correctly, your issue with API is that you have several
> threads which must use the API in parallel? I do not know if/how it
> supposed to work. Maybe someone more versed in APIs can jump in?
>
> Best
> ben
>
> > -Original Message-
> > From: vpp-dev@lists.fd.io On Behalf Of Chris Luke
> > via lists.fd.io
> > Sent: mercredi 18 novembre 2020 00:09
> > To: Aniket Pugaonkar ; Benoit Ganne (bganne)
> >
> > Cc: vpp-dev@lists.fd.io
> > Subject: Re: [EXTERNAL] Re: [vpp-dev] vppctl fails from within the
> > application (system cmd returns 256)
> >
> > On this line in the trace:
> >
> >
> >
> > [pid 2536742] socket(AF_UNIX, SOCK_STREAM, 0) = 0
> >
> >
> >
> > It says it’s returning file descriptor 0 for the socket. Similarly other
> > file opens and subsequent closes are using descriptor 0. 0 is normally
> > stdin. Are stdin & out closed? That could cause all kinds of strange
> > issues, especially when it tries to print the results to a closed stdout
> > descriptor.
> >
> >
> >
> > Chris.
> >
> >
> >
> > From: vpp-dev@lists.fd.io On Behalf Of Aniket
> > Pugaonkar
> > Sent: Tuesday, November 17, 2020 17:04
> > To: Benoit Ganne (bganne)
> > Cc: vpp-dev@lists.fd.io
> > Subject: [EXTERNAL] Re: [vpp-dev] vppctl fails from within the
> application
> > (system cmd returns 256)
> >
> >
> >
> > sorry, forgot to reply-all
> >
> >
> >
> > Hi Ben,
> >
> >
> >
> > When i use the same command in sample test application (just int
> main()..)
> > they work fine. but when I add them in my multithreaded application, it
> > does not work. Please see below Strace output of the application. even
> > fully specifying path to vppctl and cli.sock is not working
> >
> >
> >
> > since it is multithreaded, the main process creates the app
> > (vppcom_app_create).
> >
> > another thread configures the interfaces using the CLI (vppctl) - which
> is
> > failing these commands
> >
> > one thread is using VCL to receive, another thread is using VCL to
> > transmit.
> >
> > before VCL Rx and Tx threads are started, configuration thread tries to
> > configure the VPP interface using the CLI.
> >
> >
> >
> > We ran into issues while making this application (that uses VCL) work
> > with another application that used VAPI to configure VPP, and had to
> > revert back the code to vpp cli for other application.
> >
> >
> >
> > commands that fail from my multithreaded application:
> >
> > /usr/bin/vppctl -s /run/vpp/cli.sock create sub-interfaces
> > HundredGigabitEthernet12/0/0 701
> >
> > /usr/bin/vppctl -s /run/vpp/cli.sock set interface state
> > HundredGigabitEthernet12/0/0 up
> >
> > /usr/bin/vppctl -s /run/vpp/cli.sock set interface state
> > HundredGigabitEthernet12/0/0.701up
> >
> > /usr/bin/vppctl -s /run/vpp/cli.sock set interface ip address
> > HundredGigabitEthernet12/0/0.701 fd0d:1:2:cc:a5a5:301f:fe3a:a5a5/64
> >
> >
> >
> >
> >
> >
> >
> > [pid 2536742] rt_sigaction(SIGCHLD, {sa_handler=SIG_DFL, sa_mask=[],
> > sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7fbced84f790},
> > {sa_handler=0x55ee9d32d180, sa_mask=[], sa_flags=SA_RESTORER|SA_RESTART,
> > sa_restorer=0x7fbced84f790}, 8) = 0
> > [pid 2536742] execve("/usr/bin/vppctl", ["/usr/bin/vppctl", "-s",
> > "/run/vpp/cli.sock", "ip", "mroute", "add",
> > "ff38:23:2001:5b0:2000::3002/128", "via", "tuntap-0", "Accept"],
> > 0x55ee9ead72c0 /* 27 vars */) = 0
> > [pid 2536742] brk(NULL) = 0x55fce62d4000
> > [pid 2536742] arch_prctl(0x3001 /* ARCH_??? */,
Re: [vpp-dev] Supported distributions.
IMO having list of supported operationg systems is pointless, verifying against that particular list just makes everybody life harder. We waste more power and we pollute atmosphere more :) Instead i think we should have list of dependencies with minimal and preferred version. i.e. Mandatory: gcc: minimal 7.0 preferred 9.0 cmake: minimal 3.10, preferred 3.13 Optional: libbpf: …. We are mixing today 2 different things: packaging for specific distro and making sure that code can work with specific build/runtime dependencies. Result of that is that we have debian-9 verify job which does not use debian-9 provided compiler and cmake so it brings zero value. — Damjan > On 18.11.2020., at 17:22, Paul Vinciguerra wrote: > > Expanding the audience of https://gerrit.fd.io/r/c/vpp/+/28721 > > > Patch Set 2: > > > > Am I correct if I summarize your point as: > > 1) we should document the distribution we officially support (this was the > > goal of the wiki page you setup) > > 2) as long as we do not break this list we should be allowed to use new > > tools etc. (which might be breaking other, unsupported distribution) > > > > If so, I agree with you but I think I disagree about the list of supported > > distribution :) > > Right now we run CI on: > > - Ubuntu 18.04 and 20.04 > > - Debian 9 and 10 > > - CentOS 7 and 8 > > I'd say this is what we currently support :) (but again: it is my own > > personal view here, and obviously I am a bit biased on the deb9 subject ;) > > ). > > There was discussion during last community call about dropping CentOS 7 > > support and I think the consensus was to keep it for now, but we might drop > > it for 21.01 (or something along that line). > > > > Probably the best should be to have that discussion directly on the ml and > > during the community calls instead of in this ticket. > > Everything on the wiki is wrong! It was right at some point in time, but > that time has passed. If it is right, it is a coincidence. The info was put > there to try to form a consensus, but no one agreed. > > If we can get a consensus, it should be memorialized in a README type doc in > the repo and the wiki can be removed or pointed to the repo. > > I don't know the history with deb9 for you, or who needs/wants it. I have > nothing against it. We should know how long we are to maintain it for, yes? > Is there a reason we can't support it by building a current python in the > makefile instead? > > I'd characterize #2 somewhat differently. People should be > allowed/encouraged to introduce new tools, but they need to be tested. Last > year, The folks at Netgate started pushing changes for Centos 8. I wasn't > approving them, not because I wanted to hold anyone up, but because they > didn't work for me on a fresh Centos 8 container. I was told that as long as > they didn't fail the CI, I could/should approve them. They shouldn't be > blocked from having the feature, but it has to still be tested/work. > > Paul > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#18087): https://lists.fd.io/g/vpp-dev/message/18087 Mute This Topic: https://lists.fd.io/mt/78344343/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] why tunnel interfaces do not support device-input feature?
I don't know if this is useful for anyone or not. I posted https://wiki.fd.io/images/a/a6/VPP_node_graph.svg It is impossible to view at once, but you can search for a node and go from there. On Wed, Nov 18, 2020 at 11:05 AM Damjan Marion via lists.fd.io wrote: > > device-input feature arch is build for features which needs to deal with > raw ethernet frames > before they are processed and before we know to which software interface > packet belongs (including the information if interface is in l2 or l3 > mode). So there is no many tunnelling protocols which will even be > candidates for this arc. Tunnel encaps which doesn’t carry inner ethernet > header will simply not work. > People should think twice before deciding to build any feature which hangs > on that arc, as likely there is more appropriate one to use. > Pretty much the same applies to interface-output. > > > > On 18.11.2020., at 11:15, Neale Ranns via lists.fd.io cisco@lists.fd.io> wrote: > > > > > > Hi Ye, > > > > Some comments inline... > > > > On 17/11/2020 02:34, "vpp-dev@lists.fd.io on behalf of 叶东岗" < > vpp-dev@lists.fd.io on behalf of y...@wangsu.com> wrote: > > > >Hi all: > > > >why tunnel interfaces do not support device-input feature? > > > > No one has asked for/contributed such support. If you're volunteering, > here's some advice. > > > > Taking the feature arc always costs performance, but we accept that. > What is harder to accept is a performance degradation when there are no > features configured. > > > > Devices are 'physical' interfaces, they represent an interface from VPP > to the external world. This means they are read by nodes in poll mode, one > device at a time. They therefore have the luxury of knowing that all > packets in the vector/frame come from the same device. Virtual interfaces > don't have that luxury, so the check for 'are there features on the arc' > would be per buffer, not per-packet, this would be a noticeable performance > cost. > > > >why esp packets do not go through ipsec interface's > "interface-output" > >node? > > > > The actions for TX on a virtual interface are different. The equivalent > node is 'adj-midchain-tx'. Running the 'interface-output' arc here would be > possible, with a negligible performance cost because the adj can cache the > feature arc's state. > > > > /neale > > > >I think it's no bad idea to keep some features consistency of all > >interface in spite of an little performance degradation? > > > > > >Best regards, > >Ye Donggang > > > > > > > > > > > > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#18086): https://lists.fd.io/g/vpp-dev/message/18086 Mute This Topic: https://lists.fd.io/mt/78307484/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] Supported distributions.
Expanding the audience of https://gerrit.fd.io/r/c/vpp/+/28721 > Patch Set 2: > > Am I correct if I summarize your point as: > 1) we should document the distribution we officially support (this was the goal of the wiki page you setup) > 2) as long as we do not break this list we should be allowed to use new tools etc. (which might be breaking other, unsupported distribution) > > If so, I agree with you but I think I disagree about the list of supported distribution :) > Right now we run CI on: > - Ubuntu 18.04 and 20.04 > - Debian 9 and 10 > - CentOS 7 and 8 > I'd say this is what we currently support :) (but again: it is my own personal view here, and obviously I am a bit biased on the deb9 subject ;) ). > There was discussion during last community call about dropping CentOS 7 support and I think the consensus was to keep it for now, but we might drop it for 21.01 (or something along that line). > > Probably the best should be to have that discussion directly on the ml and during the community calls instead of in this ticket. Everything on the wiki is wrong! It was right at some point in time, but that time has passed. If it is right, it is a coincidence. The info was put there to try to form a consensus, but no one agreed. If we can get a consensus, it should be memorialized in a README type doc in the repo and the wiki can be removed or pointed to the repo. I don't know the history with deb9 for you, or who needs/wants it. I have nothing against it. We should know how long we are to maintain it for, yes? Is there a reason we can't support it by building a current python in the makefile instead? I'd characterize #2 somewhat differently. People should be allowed/encouraged to introduce new tools, but they need to be tested. Last year, The folks at Netgate started pushing changes for Centos 8. I wasn't approving them, not because I wanted to hold anyone up, but because they didn't work for me on a fresh Centos 8 container. I was told that as long as they didn't fail the CI, I could/should approve them. They shouldn't be blocked from having the feature, but it has to still be tested/work. Paul -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#18085): https://lists.fd.io/g/vpp-dev/message/18085 Mute This Topic: https://lists.fd.io/mt/78344343/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] why tunnel interfaces do not support device-input feature?
device-input feature arch is build for features which needs to deal with raw ethernet frames before they are processed and before we know to which software interface packet belongs (including the information if interface is in l2 or l3 mode). So there is no many tunnelling protocols which will even be candidates for this arc. Tunnel encaps which doesn’t carry inner ethernet header will simply not work. People should think twice before deciding to build any feature which hangs on that arc, as likely there is more appropriate one to use. Pretty much the same applies to interface-output. > On 18.11.2020., at 11:15, Neale Ranns via lists.fd.io > wrote: > > > Hi Ye, > > Some comments inline... > > On 17/11/2020 02:34, "vpp-dev@lists.fd.io on behalf of 叶东岗" > wrote: > >Hi all: > >why tunnel interfaces do not support device-input feature? > > No one has asked for/contributed such support. If you're volunteering, > here's some advice. > > Taking the feature arc always costs performance, but we accept that. What is > harder to accept is a performance degradation when there are no features > configured. > > Devices are 'physical' interfaces, they represent an interface from VPP to > the external world. This means they are read by nodes in poll mode, one > device at a time. They therefore have the luxury of knowing that all packets > in the vector/frame come from the same device. Virtual interfaces don't have > that luxury, so the check for 'are there features on the arc' would be per > buffer, not per-packet, this would be a noticeable performance cost. > >why esp packets do not go through ipsec interface's "interface-output" >node? > > The actions for TX on a virtual interface are different. The equivalent node > is 'adj-midchain-tx'. Running the 'interface-output' arc here would be > possible, with a negligible performance cost because the adj can cache the > feature arc's state. > > /neale > >I think it's no bad idea to keep some features consistency of all >interface in spite of an little performance degradation? > > >Best regards, >Ye Donggang > > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#18084): https://lists.fd.io/g/vpp-dev/message/18084 Mute This Topic: https://lists.fd.io/mt/78307484/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] Python API modules
On Wed, Nov 18, 2020 at 4:38 AM wrote:
> > I think that generating the python code makes the most sense. The body
> of the code can still defer to the dynamically generated object, since it's
> not available until runtime anyway, but the user no longer has to resort to
> using lambdas because of the deferred bindings.
>
> Could you ellaborate for why you need to use lambdas?
>
Today, in the tests, all references to vpp_papi. have to happen after
connect, otherwise they don't exist. Let's say I want to set up a test and
use an enum from vpp_papi, it may not exist due to the deferred binding.
Instead, you have to wrap it in a lamba so that it is evaluated at use time
instead of at module load time. You could also make it a @property and
force it evaluated at run time.
> [SNIP]
> >
> > but the typedefs could become data classes and the encode/decode methods
> in the test code become unnecessary.
>
> What are you thinking about regarding the encode/decode in tests?
> E.g. for the IP address ones, they can just be deleted. Without any
> changes to PAPI...
>
> As an example:
class VppGbpContractNextHop():
def __init__(self, mac, bd, ip, rd):
self.mac = mac
self.ip = ip
self.bd = bd
self.rd = rd
def encode(self):
return {'ip': self.ip,
'mac': self.mac.packed,
'bd_id': self.bd.bd.bd_id,
'rd_id': self.rd.rd_id}
> > vl_api_ip_ecn_t.IP_API_ECN_NONE could become ip_ecn.NONE
> >
> > The IDE's could then provide type checking and auto completion. (So one
> would know that NONE was an option without referring to the sources.)
> >
> > We would need to play around with it to see how well it works.
>
> That seems like a good idea.
> Let me give you a quick Python plugin for vppapigen that does this.
>
> The packaging is going to be a challenge I guess.
>
> The packaging could be as simple as we write the files to a folder in
vpp_papi, or we could have its own setup.py and make it a plugin to
vpp_papi.
> Best regards,
> Ole
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18083): https://lists.fd.io/g/vpp-dev/message/18083
Mute This Topic: https://lists.fd.io/mt/78229638/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] VPP 21.01 F0 milestone in 3 weeks from now
Hi all, it's this time of the year again - the F0 milestone for the 21.01 VPP release is in three weeks from now: on the 9th of December 2020. According to the agreed release plan [0], that date marks the week when we will avoid making risky changes to VPP in the run-up to the RC1. In preparation to this milestone, for the feature owners, it is a good idea to take a look at the list of in-progress messages, and consider their productization adding the tests, or the removal. [0]: https://wiki.fd.io/view/Projects/vpp/Release_Plans/Release_Plan_21.01 --a /* your friendly 21.01 release manager */ -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#18082): https://lists.fd.io/g/vpp-dev/message/18082 Mute This Topic: https://lists.fd.io/mt/78341775/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] _GI_raise Error with 8 worker thread
Hi Everyone,
I send packages with the trex tool and process packages with vpp. However, when
I increase the thread count to 8, I get an error like this.
double free or corruption (!prev)
Thread 9 "vpp_wk_6" received signal SIGABRT, Aborted.
[Switching to Thread 0x7fff8bfff700 (LWP 18733)]
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb)
When my thread count is less, I don't get any errors. How can I resolve this
issue?
nano /etc/vpp/startup.conf
cpu {
skip-cores 1
workers 8
}
buffers {
buffers-per-numa 128000
}
dpdk {
dev default {
num-rx-queues 8
num-tx-queues 8
num-rx-desc 1024
num-tx-desc 1024
}
}
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18081): https://lists.fd.io/g/vpp-dev/message/18081
Mute This Topic: https://lists.fd.io/mt/78338173/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] why tunnel interfaces do not support device-input feature?
Hi Ye, Some comments inline... On 17/11/2020 02:34, "vpp-dev@lists.fd.io on behalf of 叶东岗" wrote: Hi all: why tunnel interfaces do not support device-input feature? No one has asked for/contributed such support. If you're volunteering, here's some advice. Taking the feature arc always costs performance, but we accept that. What is harder to accept is a performance degradation when there are no features configured. Devices are 'physical' interfaces, they represent an interface from VPP to the external world. This means they are read by nodes in poll mode, one device at a time. They therefore have the luxury of knowing that all packets in the vector/frame come from the same device. Virtual interfaces don't have that luxury, so the check for 'are there features on the arc' would be per buffer, not per-packet, this would be a noticeable performance cost. why esp packets do not go through ipsec interface's "interface-output" node? The actions for TX on a virtual interface are different. The equivalent node is 'adj-midchain-tx'. Running the 'interface-output' arc here would be possible, with a negligible performance cost because the adj can cache the feature arc's state. /neale I think it's no bad idea to keep some features consistency of all interface in spite of an little performance degradation? Best regards, Ye Donggang -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#18080): https://lists.fd.io/g/vpp-dev/message/18080 Mute This Topic: https://lists.fd.io/mt/78307484/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] Python API modules
> I think that generating the python code makes the most sense. The body of > the code can still defer to the dynamically generated object, since it's not > available until runtime anyway, but the user no longer has to resort to using > lambdas because of the deferred bindings. Could you ellaborate for why you need to use lambdas? > I imagined it would work like a regular module: > > >>> import vpp_papi.plugins.map as map > >>> dir(map) > ... > >>> help(map) > > vppapigen would generate stubs such as: > > vpp_papi.plugins.map.py: > > def map_add_domain(client_index: u32, context: u32, ip6_prefix: IPV6Network, > ip4_prefix: IPV6Network, ip6_src: IPV6Interface, ea_bits_len : u8, > psid_offset : u8, psid_length : u8, mtu: u16, tag : str ) -> i32: >"""docstring from .api block comment >""" > > > > The user, of course, still needs to connect to VPP for their code to run. > > but the typedefs could become data classes and the encode/decode methods in > the test code become unnecessary. What are you thinking about regarding the encode/decode in tests? E.g. for the IP address ones, they can just be deleted. Without any changes to PAPI... > vl_api_ip_ecn_t.IP_API_ECN_NONE could become ip_ecn.NONE > > The IDE's could then provide type checking and auto completion. (So one would > know that NONE was an option without referring to the sources.) > > We would need to play around with it to see how well it works. That seems like a good idea. Let me give you a quick Python plugin for vppapigen that does this. The packaging is going to be a challenge I guess. Best regards, Ole -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#18079): https://lists.fd.io/g/vpp-dev/message/18079 Mute This Topic: https://lists.fd.io/mt/78229638/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [EXTERNAL] Re: [vpp-dev] vppctl fails from within the application (system cmd returns 256)
Indeed, stdin seems to be closed and vppctl is not written with that in mind,
just check
https://git.fd.io/vpp/tree/src/vpp/app/vppctl.c#n223 or
https://git.fd.io/vpp/tree/src/vpp/app/vppctl.c#n267 for examples... If you
have s->fd == STDIN_FILENO (as it seems to be the case here) things are going
to break.
If I understand correctly, your issue with API is that you have several threads
which must use the API in parallel? I do not know if/how it supposed to work.
Maybe someone more versed in APIs can jump in?
Best
ben
> -Original Message-
> From: vpp-dev@lists.fd.io On Behalf Of Chris Luke
> via lists.fd.io
> Sent: mercredi 18 novembre 2020 00:09
> To: Aniket Pugaonkar ; Benoit Ganne (bganne)
>
> Cc: vpp-dev@lists.fd.io
> Subject: Re: [EXTERNAL] Re: [vpp-dev] vppctl fails from within the
> application (system cmd returns 256)
>
> On this line in the trace:
>
>
>
> [pid 2536742] socket(AF_UNIX, SOCK_STREAM, 0) = 0
>
>
>
> It says it’s returning file descriptor 0 for the socket. Similarly other
> file opens and subsequent closes are using descriptor 0. 0 is normally
> stdin. Are stdin & out closed? That could cause all kinds of strange
> issues, especially when it tries to print the results to a closed stdout
> descriptor.
>
>
>
> Chris.
>
>
>
> From: vpp-dev@lists.fd.io On Behalf Of Aniket
> Pugaonkar
> Sent: Tuesday, November 17, 2020 17:04
> To: Benoit Ganne (bganne)
> Cc: vpp-dev@lists.fd.io
> Subject: [EXTERNAL] Re: [vpp-dev] vppctl fails from within the application
> (system cmd returns 256)
>
>
>
> sorry, forgot to reply-all
>
>
>
> Hi Ben,
>
>
>
> When i use the same command in sample test application (just int main()..)
> they work fine. but when I add them in my multithreaded application, it
> does not work. Please see below Strace output of the application. even
> fully specifying path to vppctl and cli.sock is not working
>
>
>
> since it is multithreaded, the main process creates the app
> (vppcom_app_create).
>
> another thread configures the interfaces using the CLI (vppctl) - which is
> failing these commands
>
> one thread is using VCL to receive, another thread is using VCL to
> transmit.
>
> before VCL Rx and Tx threads are started, configuration thread tries to
> configure the VPP interface using the CLI.
>
>
>
> We ran into issues while making this application (that uses VCL) work
> with another application that used VAPI to configure VPP, and had to
> revert back the code to vpp cli for other application.
>
>
>
> commands that fail from my multithreaded application:
>
> /usr/bin/vppctl -s /run/vpp/cli.sock create sub-interfaces
> HundredGigabitEthernet12/0/0 701
>
> /usr/bin/vppctl -s /run/vpp/cli.sock set interface state
> HundredGigabitEthernet12/0/0 up
>
> /usr/bin/vppctl -s /run/vpp/cli.sock set interface state
> HundredGigabitEthernet12/0/0.701up
>
> /usr/bin/vppctl -s /run/vpp/cli.sock set interface ip address
> HundredGigabitEthernet12/0/0.701 fd0d:1:2:cc:a5a5:301f:fe3a:a5a5/64
>
>
>
>
>
>
>
> [pid 2536742] rt_sigaction(SIGCHLD, {sa_handler=SIG_DFL, sa_mask=[],
> sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7fbced84f790},
> {sa_handler=0x55ee9d32d180, sa_mask=[], sa_flags=SA_RESTORER|SA_RESTART,
> sa_restorer=0x7fbced84f790}, 8) = 0
> [pid 2536742] execve("/usr/bin/vppctl", ["/usr/bin/vppctl", "-s",
> "/run/vpp/cli.sock", "ip", "mroute", "add",
> "ff38:23:2001:5b0:2000::3002/128", "via", "tuntap-0", "Accept"],
> 0x55ee9ead72c0 /* 27 vars */) = 0
> [pid 2536742] brk(NULL) = 0x55fce62d4000
> [pid 2536742] arch_prctl(0x3001 /* ARCH_??? */, 0x7ffc94d85710) = -1
> EINVAL (Invalid argument)
> [pid 2536742] access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file
> or directory)
> [pid 2536742] openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 0
> [pid 2536742] fstat(0, {st_mode=S_IFREG|0644, st_size=62967, ...}) = 0
> [pid 2536742] mmap(NULL, 62967, PROT_READ, MAP_PRIVATE, 0, 0) =
> 0x7ffb8ce4f000
> [pid 2536742] close(0) = 0
> [pid 2536742] openat(AT_FDCWD, "/lib64/libvppinfra.so.20.05.1",
> O_RDONLY|O_CLOEXEC) = 0
> [pid 2536742] read(0,
> "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0p\230\0\0\0\0\0\0"..., 832)
> = 832
> [pid 2536742] fstat(0, {st_mode=S_IFREG|0755, st_size=509240, ...}) = 0
> [pid 2536742] mmap(NULL, 8192, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ffb8ce4d000
> [pid 2536742] mmap(NULL, 2603336, PROT_READ|PROT_EXEC,
> MAP_PRIVATE|MAP_DENYWRITE, 0, 0) = 0x7ffb8c9bb000
> [pid 2536742] mprotect(0x7ffb8ca35000, 2093056, PROT_NONE) = 0
> [pid 2536742] mmap(0x7ffb8cc34000, 8192, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 0, 0x79000) = 0x7ffb8cc34000
> [pid 2536742] mmap(0x7ffb8cc36000, 2376, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7ffb8cc36000
> [pid 2536742] close(0) = 0
> [pid 2536742] openat(AT_FDCWD, "/lib64/libm.so.6", O_RDONLY|O_CLOEXEC) = 0
> [pid 2536742]
