Ray,
> On 29 Sep 2018, at 02:01, Rui Cai via Lists.Fd.Io
> wrote:
>
> Thanks for the explanation, Dave! It makes sense.
>
> In general, does VPP not use the behavior of queuing and reinjection for any
> scenario due to the resource exhaustion attack reason? Or is there such
> pattern (queu
Hi,
I am trying to open dpdk log (based on VPP upstream code),
but I cannot see any dpdk log output in /var/log/vpp/vpp.log
after adding "log-level debug" in dpdk section of startup.conf.
Thanks,
Eason-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online
Thanks for the explanation, Dave! It makes sense.
In general, does VPP not use the behavior of queuing and reinjection for any
scenario due to the resource exhaustion attack reason? Or is there such
pattern (queue & re-inject) for a particular scenario I can study?
Thanks,
-Ray
From: Dave Bar
This is deliberate, traditional router behavior.
Alternatives involving queueing packets for reinjection after glean resolution
events give rise to resource exhaustion attacks. Mitigating that kind of attack
burns clock cycles, which in turn gives rise to a different kind of attack.
HTH... Dave
Hello VPP experts:
I have question about the behavior of ip4(6)-glean nodes. In particular, I'm
noticing the node is dropping the original packet that triggered glean process.
The VPP I'm running is 18.07 with DPDK 18.02.
I'm using VPP as a simple forwarding application where final destination'
> On 28 Sep 2018, at 18:39, Stephen Hemminger
> wrote:
>
> Sorry for top posting Gmail on phone is stupid.
no prob, we all top post here most of the time ;)
> A process can do introspection by doing dlopen with NULL as filename. Then
> look up symbols from there.
ack
Please note that stil
Sorry for top posting Gmail on phone is stupid.
A process can do introspection by doing dlopen with NULL as filename. Then
look up symbols from there.
On Fri, Sep 28, 2018, 5:22 PM Damjan Marion wrote:
>
>
> > On 28 Sep 2018, at 12:13, Stephen Hemminger
> wrote:
> >
> > Having supported hardwar
Just to ask: a supported (64-bit (😊)) PCI-ID table, that plus vendor strings,
or something else?
Makes sense but as Damjan wrote we're swamped right now. If you have time, go
for it. Stick the results in the stats segment, maybe?
D.
-Original Message-
From: vpp-dev@lists.fd.io On Beh
> On 28 Sep 2018, at 12:13, Stephen Hemminger
> wrote:
>
> Having supported hardware list buried in DPDK plugin code is a nuisance.
> Could the table be generated at build time maybe from pmdinfo or using dlopen
> to lookup symbols?
Pure lack of manpower to cleanup this stuff.
Please note
Does the "make pkg-rpm" only recognize the committed code at stable branch?
wangchuan...@163.com
发件人： wangchuan...@163.com
发送时间： 2018-09-28 20:14
收件人： vpp-dev
主题： code changes works well at debug, but bad at pkg-rpm
Hi all,
I add some code at vpp stable 1804, and it works good with "make b
Hi all,
I add some code at vpp stable 1804, and it works good with "make build &&
make run" .
But it seems to be same with origin with installing the pkg-rpm from "make
pkg-rpm ".
Does it need some operation else for "make pkg-rpm"?
centos7.5 + vpp-stable-1804
1、make build && make run
2、ma
Dear all,
This is just a gentle reminder that we have just few days left for F0 [1].
Please, make sure you have your patches with API changes merged before the
deadline (Oct 3rd).
[1] https://wiki.fd.io/view/Projects/vpp/Release_Plans/Release_Plan_18.10
Thanks and regards,
--
Marco V
SUSE LI
Having supported hardware list buried in DPDK plugin code is a nuisance.
Could the table be generated at build time maybe from pmdinfo or using
dlopen to lookup symbols?
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#10702): https://lists.fd.io/g/vp
13 matches
Mail list logo
