HiI am trying to add a new node to parse packet data after all vxlan decoding,
ip4-input and before doing IP lookup. This code flow is is working fine for
packets coming from vxlan-gpe/IPSec tunnels and not for vxlan.Traffic is
working fine except not going through this new "test-node".
The
Hi Venkat,
Before doing ACL checks, acl-plugin checks the establshed sessions on
the given interface.
If an already established session is hit the action is set to "3" and
no further ACL check is done, which is what you see in your output.
For that case, the ACL# in the trace is a special-case
Hi Sergey,
have a look at 22963; the checkstyle job requires a particular version of
checkstyle, it’s WIP in progress to update it, as well as to give us an option
to selectively try out clang-format on some files.
However; I think this functionality of this patch has more fundamental
Hi Sergey,
The rationale behind this makes sense to me,
though I still think it should be still a distinct new entity rather than
“extending” the semantics of the existing one.
We had about a year worth of rather disruptive injecting types in API
so the users can distinguish a u32 IPv4
Sounds like you may not have enabled the “test-node” feature on the rx
sw_if_index. “show interface features”... Note that if the packet comes
from a bridge group, I suspect that you’ll need to enable the feature on the
bvi vs the rx interface.
This is the kind of problem which “pcap dispatch
Hello Andrew. Thanks for quick response.
In a nutshell - yes, gauges are something I am also currently using to
track the number of entries in a bihash table(for example), however gauge
update will be done each time when the stats segment performs processing.
Idea was to track value more rapidly
Hi Sergey,
> In a nutshell - yes, gauges are something I am also currently using to track
> the number of entries in a bihash table(for example), however gauge update
> will be done each time when the stats segment performs processing. Idea was
> to track value more rapidly w/o increasing
Greetings VPP community.
Recently I've created a small patch for counter.h core file.
For some reason several patchsets are failing with checkstyle issues.
https://gerrit.fd.io/r/c/vpp/+/28843
Fixing of the change by indent causes the entire file to be reworked since
the old file does not fit
Hello everyone,
I am using VPP 19.08 and running it in simple forwarding mode. It's
handling thousands of connections per second and over 8 Gbps of throughput.
I am curious to know what the general experience has been with CPU usage
per worker while increasing the number of workers and queues. I
Hi Florin,
In the 1 iperf connection test, I get different numbers every time I run.
When I ran today
- iperf and vpp in the same numa core as pci device: 50Gbps (although in
different runs I saw 30Gbps also)
- vpp in the same numa core as pci device, iperf in the other numa : 28Gbps
- vpp and
Hi Florin,
Sure yes, and better still would be for the app to integrate directly with
VPP to even avoid the shared fifo copy, I assume. It's just that the VCL
library gives a quick way to get some benchmark numbers with existing
applications. Thanks for all the help. I have a much better idea
Hi Vijay,
Oh, by no means. Builtin applications, i.e., applications that run within the
vpp process, are definitely possible (see plugins/hs_apps/echo_client/server or
the proxy). They run “on” the vpp workers and io/ctrl events are delivered by
the session layer to those apps using callback
Hi Vijay,
Yes. Underneath, the fifos maintain a linked a list of chunks where the data is
stored. VCL could provide pointers to those in the form of iovecs and another
api to mark the data as consumed (implicitly release the chunks) once the app
is done reading. But again, the apps would have
Why not look at CSIT reports with config closest to yours ?
They test various number of scenarios with varying number of cores...
Else the question is waaay too general to say anything than “it depends”...
(Imho).
--a
> On 15 Sep 2020, at 17:39, siddarth rai wrote:
>
>
> Hello
Hi Vijay,
Currently, builtin applications can only receive data from tcp in a session’s
rx fifo. That’s a deliberate choice because, at scale, out of order data could
end up consuming a lot of buffers, i.e., buffers are queued but cannot be
consumed by the app until the gaps are filled.
Hi Florin,
I got it now.
Also, I think you mentioned the support in the VCL library for the
application to read/write/free directly from fifo buffers is not yet
present, but can be added with little effort. Is that correct?
Thanks,
Vijay
On Tue, Sep 15, 2020 at 1:31 PM Florin Coras wrote:
>
Hi Vijay,
> On Sep 15, 2020, at 8:54 AM, Vijay Sampath wrote:
>
> Hi Florin,
>
> In the 1 iperf connection test, I get different numbers every time I run.
> When I ran today
>
> - iperf and vpp in the same numa core as pci device: 50Gbps (although in
> different runs I saw 30Gbps also)
Hi Vijay,
Yes, that is the case for this iperf3 test. The data is already in user space,
and could be passed to the app in the shape of iovecs, to avoid the extra
memcpy, but the app would need to be changed to have it release the memory
whenever it’s done reading it. In case of iperf3 it
Hi all,
Just a kind reminder that RC2 tagging is tomorrow 16 September. There needs to
be some urgent work done on the LF infra side to give us a bit more of
breathing space, so I extraordinarily will have to do it earlier, at *noon
UTC*, as opposed to 18:00 UTC.
I will do the tagging once I
Hi Florin,
I just realized that maybe in the VPP case there is an extra copy - once
from mbuf to shared fifo, and once from shared fifo to application buffer.
In Linux, there is probably just the copy from kernel space to user space.
Please correct me if I am wrong. If so, what I am doing is not
Hi Florin,
Got it. So what you are saying is that TCP applications cannot directly be
linked with VPP. They have to be a separate process and go through the VCL
library, although they can be optimized to avoid 1 extra memcpy. In future,
memcpy _may_ be avoided completely, but the applications
Hi Florin,
Sure got it. The options are clear now.
Thanks,
Vijay
On Tue, Sep 15, 2020 at 2:06 PM Florin Coras wrote:
> Hi Vijay,
>
> Yes. Underneath, the fifos maintain a linked a list of chunks where the
> data is stored. VCL could provide pointers to those in the form of iovecs
> and
Thank you Andrew for taking the time and responding to my questions.
Much appreciated.
On Tue, Sep 15, 2020 at 2:01 AM Andrew Yourtchenko
wrote:
> Hi Venkat,
>
> Before doing ACL checks, acl-plugin checks the establshed sessions on
> the given interface.
>
> If an already established session
Hi all,
I want to match these two types of packets:
packets whose destination IP is 1.1.1.1;
ospf packets.
I have two ideas, but they don't work:
1. Create a table and set the mask to l3 ip4 src proto, but according to the
matching rules (packet==match) when creating a session,
24 matches
Mail list logo
