Hi Raj,
Inline.
> On May 16, 2020, at 2:30 PM, Raj Kumar wrote:
>
> Hi Florin,
>
> I am using VPP 20.05 rc0 . Should I upgrade it ?
FC: Not necessarily, as long as it’s relatively recent, i.e., it includes all
of the recent udp updates.
>
> Thanks! for providing the patch, i will try i
>>> API messages in network byte order made sense 10 years ago when I worked
>>> with a mixed x86_64 / ppc32 system. As Damjan points out, API
>>> interoperability between big-endian and little-endian systems is a boutique
>>> use-case these days.
>>>
>>> Timing is key. We won’t be able to cherry-
Hi Florin,
I am using VPP 20.05 rc0 . Should I upgrade it ?
Thanks! for providing the patch, i will try it on Monday. Actually, I am
testing in a controlled environment where I can not change the VPP
libraries. I will try it on my server.
On the UDP connection; yes, the error EINPROGRESS was
Hi Raj,
Assuming you are trying to open more than one connected udp session, does this
[1] solve the problem (note it's untested)?
To reproduce legacy behavior, this allows you to listen on VPPCOM_PROTO_UDPC
but that is now converted by vcl into a udp listen that propagates with a
“connected”
Hi Raj,
Are you using master latest/20.05 rc1 or something older? The fact that you’re
getting a -115 (EINPROGRESS) suggests you might’ve marked the connection as
“non-blocking” although you created it as blocking. If that’s so, the return
value is not an error.
Also, how if vpp crashing? Ar
Hi Florin,
I tried to connect on receiving the first UDP packet . But, it did not
work. I am getting error -115 in the application and VPP is crashing.
This is something I tried in the code (udp receiver) -
sockfd = vppcom_session_create(VPPCOM_PROTO_UDP, 0);
rv_vpp = vppcom_session_bind (sockfd,
> On May 16, 2020, at 9:52 AM, Andrew 👽 Yourtchenko wrote:
>
> On 5/16/20, Dave Barach (dbarach) wrote:
>> API messages in network byte order made sense 10 years ago when I worked
>> with a mixed x86_64 / ppc32 system. As Damjan points out, API
>> interoperability between big-endian and little
Very valid point. Endianness is only aspect. Accidental size changes on the
wire is different.
But this drifted very far astray from my original question: if we keep
shuffling the bits on wire regardless, how much of a value does a meticulous
CRC tracking process provides ? i see it as actively
On 5/16/20, Dave Barach (dbarach) wrote:
> API messages in network byte order made sense 10 years ago when I worked
> with a mixed x86_64 / ppc32 system. As Damjan points out, API
> interoperability between big-endian and little-endian systems is a boutique
> use-case these days.
>
> Timing is key
API messages in network byte order made sense 10 years ago when I worked with a
mixed x86_64 / ppc32 system. As Damjan points out, API interoperability between
big-endian and little-endian systems is a boutique use-case these days.
Timing is key. We won’t be able to cherry-pick API message handl
As a user of these APIs I would hugely appreciate work be done on the API
framework to make it more usable (don't require callbacks) fix the automatic
endian conversion it already generates, improve support for argument additions
(these are easy to support in a backward compatible way), and mayb
I was hesitating to write exactly that - so at least I am not alone in thinking
this... :-)
With my RelMgr hat on I would be seeing this as to have a -2’d patch in gerrit
whose existence I can announce in 20.05 release notes, which would apply to
both stable/2005 branch and to master branch,
Knowing that even hard-core big-endian systems like PowerPC decided to switch
to Little endian and that situation where binary api will be exchanged between
BE and LE systems is extremely small, maybe we should consider removing endian
conversion from APIs and simply represent data
in the nativ
1) “jobs are broken” is a bit of a strong assessment for this case - it would
be more precise to say “sporadic failures” - there are plenty of blue bullets
after and before that job:
https://jenkins.fd.io/view/vpp/job/vpp-merge-master-centos7/
(the trend overall is not stellar -
https://jenki
14 matches
Mail list logo
