> 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
?
>
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
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 sta
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
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
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 allowe
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
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
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 preparati
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_
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
> 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 ell
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 goi
13 matches
Mail list logo
