Hi Praveen,
Glad it helped!
Actually the one complaining is openssl. We enforce strict certificate
verification only if the server hostname was provided at connect time.
Florin
> On Jul 24, 2019, at 7:41 PM, Praveen Kariyanahalli
> wrote:
>
> Thanks a lot. That tip helped a lot. My app_
Thanks a lot. That tip helped a lot. My app_index was not set properly
while adding my cert.
I see my client complains about the self signed certificate. Is this
expected? See logs below
Regards
-Praveen
Jul 25 02:39:02 myvpp1 vnet[1468]: create_api_loopback:330:
ecm->my_client_index 256
Jul 25
Hi Max,
Note how whenever acks go from 192.168.0.1 to 192.168.0.200, the window is
constantly 8k, it never drops, i.e., that buffer never fills. If you pick a
segment, say seq 18825 -> 20273, it’s sent at time 0.000545 and it’s acked at
0.000570. So, the ack went out after 25us and by that tim
VPP 19.04.2 Maintenance Release is starting now.
VPP Committers, please do not merge any patches into stable/1904 until I
have notified the community that the release is complete.
Thanks,
-daw-
On 7/24/2019 9:00 AM, Dave Wallace via Lists.Fd.Io wrote:
Folks,
A gentle reminder that today the
Hi Florin,
>
>Well, the question there is how large are the rx buffers. If you never see a
>zero rcv window advertised to the sender, I suspect the rx buffer is large
>enough to sustain the throughput.
Using the reference [1], you can view a dump of downloading the same file from
the same lin
Hi Max,
Inline.
> On Jul 24, 2019, at 10:09 AM, Max A. wrote:
>
>
> Hi Florin,
>
> I made a simple epoll tcp proxy (using vcl) and saw the same behavior.
>
> I increased the fifo size to 16k, but I got exactly the same effect. A full
> dump for a session with a buffer size of 16k can be ob
Hi Florin,
I made a simple epoll tcp proxy (using vcl) and saw the same behavior.
I increased the fifo size to 16k, but I got exactly the same effect. A full
dump for a session with a buffer size of 16k can be obtained by reference [1]
(192.168.0.1 is the interface on vpp, 192.168.0.200 is t
Cool, thanks for clarification!
--a
> On 24 Jul 2019, at 18:37, Florin Coras wrote:
>
> Pretty much. We advertise whatever space we have left in the fifo as opposed
> to 0 and as result linux backs off.
>
> TCP_NODELAY can force what looks like the problematic packet out sooner.
> However, b
Pretty much. We advertise whatever space we have left in the fifo as opposed to
0 and as result linux backs off.
TCP_NODELAY can force what looks like the problematic packet out sooner.
However, because of the small rx fifo, next rcv window will zero and the whole
transfer will stall there unti
Just reading the description and not having peeked into the sniffer
trace, I wondered if is it this behavior a side effect of mitigation
of [1], consequently, are the linux side sockets marked as no_delay ?
[2]
[1]: https://en.wikipedia.org/wiki/Silly_window_syndrome
[2]:
https://stackoverflow.c
Hi,
It seems that linux is reluctant to send a segment smaller than the mss, so it
probably delays sending it. Since there’s little fifo space, that’s pretty much
unavoidable.
Still, note that as you increase the number of sessions, if all send traffic at
the same rate, then their fair share
Dear Neale,
Thanks for your prompt response.
Answer comments inline.
On Wed, Jul 24, 2019 at 5:16 PM Neale Ranns (nranns)
wrote:
>
>
> Dear Brayan,
>
>
>
> You should always add a next-hop to a path when IP routing.
>
> Answers comments inline.
>
>
>
> /neale
>
>
>
> *De : * au nom de brayan ort
Backtrace, please.
If you feed vlib_get_node(...) a bad node index – such as ~0 - it will ASSERT.
Dave
From: vpp-dev@lists.fd.io On Behalf Of
prashan...@gmail.com
Sent: Wednesday, July 24, 2019 9:07 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] node_funcs.h:61 (vlib_get_node) assertion `(i) <
I have just added a new plugin, getting below error while vpp loading. Any
pointer would be helpful.
*node_funcs.h:61 (vlib_get_node) assertion `(i) < vec_len
(vm->node_main.nodes)' fails*
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#13564): ht
Folks,
A gentle reminder that today the VPP 19.04.2 Maintenance Release is
scheduled to begin at 1800 UTC.
If you have any late submissions that are required for 19.04.2, please
unicast me as soon as possible.
Thank you.
-daw-
"Your Friendly VPP 19.04 Release Manager"
-=-=-=-=-=-=-=-=-=-=-=
Dear Brayan,
You should always add a next-hop to a path when IP routing.
Answers comments inline.
/neale
De : au nom de brayan ortega
Date : mercredi 24 juillet 2019 à 11:25
À : "vpp-dev@lists.fd.io"
Objet : [vpp-dev] abf problem with arp
Dear VPP Folks,
I'm using vpp v19.08-rc0~698-g1f50bf
Hi,
See if following link helps
https://fdio-vpp.readthedocs.io/en/latest/gettingstarted/developers/vlib.html#graph-dispatcher-internals
Thanks,
Nitin
From: vpp-dev@lists.fd.io On Behalf Of
chandan.moha...@nokia.com
Sent: Wednesday, July 24, 2019 3:55 PM
To: vpp-dev@lists.fd.io
Subject: [EXT]
Hi,
>> I have searched the mailing list and know about the DPDK take buffer from
>> VPP,
Correct. VPP does two things to allow DPDK to use VPP buffers.
1. Register two mempool ops to DPDK namely “vpp” (cached/fast) and
“vpp-no-cache” (non-cached/slow). See function dpdk_buffer_pool_create()
-- Forwarded message -
From: Luca Muscariello
Date: Wed, Jul 24, 2019 at 12:31 PM
Subject: Re: [hicn-dev] [vpp-dev] VPP Router Plugin or alternatives
To:
Patch has been merged and packages are available in packagecloud as
hicn-extra-plugin-19.04
Code available here
https://githu
Hi ,
I am new to VPP.
I request,if any kind hearted soul can help me understand,the boilerplate code
in Node.c of a plugin. I want to understand the buffer / frame / next handling
of frame/next handling of node/prefetch code ,that is under both whileS() as
below.
If you can point me to any URL
Hi, everyone
I'am a newer with VPP architeture, I want't to use the vlib_buffer reference
count(such as clone) to reduce the copies,
but I'am confused with the referent count operations between the vlib_buffer
and rte_mbuf (use DPDK as the interface input), I have searched the mailing
list a
Dear VPP Folks,
I'm using vpp v19.08-rc0~698-g1f50bf8fc (master branch) and It seems there
is a bug when the abf plugin is enabled and configured in my scenario.
abf policy is defined as follows:
1- permit packets
2- route to output interface without gateway definition ( via 0.0.0.0 )
3- attachin
Hello,
Experimenting with the size of fifo, I saw a problem. The smaller the size of
the fifo, the more often tcp window overflow errors occur (Segment not in
receive window in vpp terminology). In the dump [1], is shown the data exchange
between the vpp tcp proxy (192.168.0.1) and the nginx se
23 matches
Mail list logo
