Re: [vpp-dev] MACIP ACL replace causes ip4_table_index change?

[Jon Loeliger]

On Fri, Dec 8, 2017 at 12:55 PM, Jon Loeliger  wrote:
>
>
>
>> We need to iterate the am->macip_acl_by_sw_if_index and for interfaces
>> which have the acl in question applied, reapply these new tables to these
>> interfaces so the already active macip acl remained active.
>>
>
> Ah, I see
>

I'm not convinced this is the issue.  I added that loop, and it doesn't
change things.  Specifically, a->ip4_table_index is 0, not 3 after the
creation of the classify tables.

So, here is sort of a trace through some key places of the
classify table construction.  It follows the API sequence I
outlined in an earlier message (create MACIP with one permit rule,
then bind to interface, then modify that MACIP's rule to deny
and update it using macip_acl_add_replace).

I'll annotate this some.

Here is the initial creation of the classify tables:

macip_acl_add_list: looks like a create
macip_create_classify_tables: top a->count 1
macip_create_classify_tables: last_table before 4294967295

Now we create the rules in reverse order:

macip_create_classify_tables: ARP looop top
macip_create_classify_tables: ARP loop last_table 0
macip_create_classify_tables: IP[46] loop top
macip_create_classify_tables: IP[46]  loop last_table 1
macip_create_classify_tables: IP[46]  loop last_table 2
macip_create_classify_tables: IP[46]  loop last_table 3
macip_create_classify_tables: ip4_t_i 3
macip_create_classify_tables: ip6_t_i 3
macip_create_classify_tables:  l2_t_i 3

That leaves last_table at 3, the most recently created rule,
with a chain from 0 through 3:

vpp# show classify tables
  TableIdx  Sessions   NextTbl  NextNode
 0 1 1-1
  Heap: 3 objects, 204 of 2k used, 76 free, 0 reclaimed, 1k overhead, 8188k
capacity
  nbuckets 32, skip 0 match 2 flag 0 offset 0
  mask 
  linear-search buckets 0
 1 1 2-1
  Heap: 3 objects, 204 of 2k used, 76 free, 0 reclaimed, 1k overhead, 8188k
capacity
  nbuckets 32, skip 0 match 2 flag 0 offset 0
  mask 
  linear-search buckets 0
 2 1 3-1
  Heap: 3 objects, 236 of 2k used, 76 free, 0 reclaimed, 1k overhead, 8188k
capacity
  nbuckets 32, skip 0 match 3 flag 0 offset 0
  mask :

   0020: 
  linear-search buckets 0
 3 1-1 0
  Heap: 3 objects, 204 of 2k used, 76 free, 0 reclaimed, 1k overhead, 8188k
capacity
  nbuckets 32, skip 0 match 2 flag 0 offset 0
  mask 

Now I bind that MACIP to the interface, and get:

vpp# show acl-plugin macip interface
  sw_if_index 0: -1
  sw_if_index 1: 0
vpp# show acl-plugin macip acl
MACIP acl_index: 0, count: 1 (true len 1) tag {bob} is free pool slot: 0
  ip4_table_index 3, ip6_table_index 3, l2_table_index 3
rule 0: ipv4 action 1 ip 0.0.0.0/0 mac 00:00:00:00:00:00 mask
00:00:00:00:00:00

Now I update the MACIP rule, changing "permit" to "deny".
And I call macip_acl_add_replace():

macip_acl_add_list: replacing ACLs now, acl_list_index is 0
macip_acl_interface_add_acl: macip_acl_index 0
macip_acl_add_list: looks like a replace
macip_create_classify_tables: top a->count 1
macip_create_classify_tables: last_table before 4294967295

That's just like before.  Good.

And now we count down the existing matching rules:

macip_create_classify_tables: ARP looop top
macip_create_classify_tables: ARP loop last_table 3
macip_create_classify_tables: IP[46] loop top
macip_create_classify_tables: IP[46]  loop last_table 2
macip_create_classify_tables: IP[46]  loop last_table 1
macip_create_classify_tables: IP[46]  loop last_table 0

And leave last_table at 0.
Which we then store in the {ip4,ip6,l2}_table_index variables:

macip_create_classify_tables: ip4_t_i 0
macip_create_classify_tables: ip6_t_i 0
macip_create_classify_tables:  l2_t_i 0

This is my loop added to the bottom of macip_acl_add_list():

  for (i = 0; i < vec_len (am->macip_acl_by_sw_if_index); i++)
{
  vlib_cli_output (vm, "%s: check swif %d\n", __func__, i);

  if (am->macip_acl_by_sw_if_index[i] == *acl_list_index)
{
  vlib_cli_output (vm, "%s: re-add acl_list_index %d\n", __func__,
*acl\
_list_index);
  macip_acl_interface_add_acl (am, i, *acl_list_index);
}
}


macip_acl_add_list: replacing ACLs now, acl_list_index is 0
macip_acl_add_list: check swif 0
macip_acl_add_list: check swif 1
macip_acl_add_list: re-add acl_list_index 0
macip_acl_interface_add_acl: macip_acl_index 0

So the MACIP ACL is applied to the SW IF, I believe, but
the MACIP ACL itself appears to be pointing to the wrong
end of the classify table chain in either the "create" case,
or in the "replace" case.  But I think they should be the same.

HTH,
jdl
_

Re: [vpp-dev] How can i use VPP as MPLS PE/P device

[Michael Borokhovich]

So, for the control plane, we can use e.g., FRR that will populate Linux's
FIB and MPLS table. Then, we need to sync this info to VPP's FIB and VPP's
MPLS table.

While the "router plugin" provides support for FIB synchronization, there
is no support for MPLS sync. Does anyone know if there are plans to add
this MPLS support to router plugin? Otherwise, what would be the
alternative best way of synchronizing Linux MPLS table with VPP?

Thanks!
Michael.


On Wed, Dec 6, 2017 at 2:15 PM, Luke, Chris  wrote:

> But to make sure we’re clear, while VPP can provide the dataplane of a
> P/PE, but something else has to provide the control plane (eg, LDP, BGP,
> SDN controller, etc)
>
>
>
> Chris.
>
>
>
> *From: * on behalf of "Neale Ranns (nranns)"
> 
> *Date: *Wednesday, December 6, 2017 at 09:33
> *To: *"wangchuan...@163.com" , vpp-dev <
> vpp-dev@lists.fd.io>
> *Subject: *Re: [vpp-dev] How can i use VPP as MPLS PE/P device
>
>
>
>
>
> Another hastily assembled, on-demand guide:
>
>   https://wiki.fd.io/view/VPP/MPLS_FIB
>
>
>
> /neale
>
>
>
> *From: * on behalf of "wangchuan...@163.com"
> 
> *Date: *Wednesday, 6 December 2017 at 09:11
> *To: *vpp-dev 
> *Subject: *[vpp-dev] How can i use VPP as MPLS PE/P device
>
>
>
> hi all，
>
> I want to configure my testing MPLS network.
>
> how can I configure VPP to act as PE or P using CLI cmd?
>
> who can help?
>
>
>
>
> best regards!
>
>
> --
>
> simon wang
>
>
> ___
> vpp-dev mailing list
> vpp-dev@lists.fd.io
> https://lists.fd.io/mailman/listinfo/vpp-dev
>
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] MACIP ACL replace causes ip4_table_index change?

[Jon Loeliger]

On Fri, Dec 8, 2017 at 12:34 PM, Andrew Yourtchenko 
wrote:

> Jon,
>
> Do you have an api trace you could throw in my direction unicast ?
>

I'd have to work at that quite a bit as I am using a totally new and
different UI to drive these API calls...  I can outline it for you:

macip_index = create macip acl with one rule "permit"
call interface bind (some sw_if_index, macip_index)

show the classifier tables
show the MACIP interface bindings
show the MACIP acls

call macip_acl_add_replace(macip_index, "change rule to deny")

show the new classifier tables (look ok)
show the MACIP interface bindings (look ok)
show the MACIP acls (look ok except the {ip4,ip6,l2}_table_index values
are 0; should be 3?)


> Macip_add_replace call was added later than most ACL plugins, (after
> realizing the convenience of this approach in the policy ACLs vs the
> unapply/delete acl/readd acl/reapply and for consistency), via commit
> c29940c58de3e44c0c1dd5c4eda5e0268d963b14
>

I know.  In fact, I had a different bug reported against our UI due
to the old way of removing the rules and then not getting them
re-applied upon addition correctly.

So when I saw the new API call (add_replace), I jumped on it!

I think I've just re-discovered the same underlying problem just
two layers deeper into the MACIP implementation now. :-/



> That change modified the existing “macip_acl_add_list” routine to also get
> the replace semantics, by deleting and then recreating the classifier
> tables anew.
>

I've just read through the macip_create_classifier_tables(), so yeah...


> This doesn’t work very well if the classifier tables are applied
> somewhere: they are removed, but the new tables are not applied
> automatically.
>

Right.  That's what I think I am seeing.


> We need to iterate the am->macip_acl_by_sw_if_index and for interfaces
> which have the acl in question applied, reapply these new tables to these
> interfaces so the already active macip acl remained active.
>

Ah, I see


> This is a bug. Sorry for that.
>

No worries.  I've written a bug or two in my day...


>  Since there were also tests in that commit which ideally should have
> caught this, i will also need to take a double check at what is going on
> there (my guess missing negative tests), and fix it too, but not sure I can
> pull off thumbtyping in a vi session,
>

I see your problem here. No one should have to use vi. :-)


> so I will add you to the changerequest with the fix once I have it, hope
> in a day or so.
>

Excellent!

Thank you!
jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] MACIP ACL replace causes ip4_table_index change?

[Andrew Yourtchenko]

Jon,

Do you have an api trace you could throw in my direction unicast ?

Macip_add_replace call was added later than most ACL plugins, (after realizing 
the convenience of this approach in the policy ACLs vs the unapply/delete 
acl/readd acl/reapply and for consistency), via commit 
c29940c58de3e44c0c1dd5c4eda5e0268d963b14

That change modified the existing “macip_acl_add_list” routine to also get the 
replace semantics, by deleting and then recreating the classifier tables anew.

This doesn’t work very well if the classifier tables are applied somewhere: 
they are removed, but the new tables are not applied automatically. We need to 
iterate the am->macip_acl_by_sw_if_index and for interfaces which have the acl 
in question applied, reapply these new tables to these interfaces so the 
already active macip acl remained active. This is a bug. Sorry for that.

 Since there were also tests in that commit which ideally should have caught 
this, i will also need to take a double check at what is going on there (my 
guess missing negative tests), and fix it too, but not sure I can pull off 
thumbtyping in a vi session, so I will add you to the changerequest with the 
fix once I have it, hope in a day or so.

--a

>>> On 8 Dec 2017, at 17:28, Jon Loeliger  wrote:
>>> 
>>> On Fri, Dec 8, 2017 at 11:24 AM, Jon Loeliger  wrote:
>>> On Fri, Dec 8, 2017 at 10:56 AM, Jon Loeliger  wrote:
>>> 
>>> vpp# show acl-plugin macip acl
>>> MACIP acl_index: 0, count: 1 (true len 1) tag {bob} is free pool slot: 0
>>>   ip4_table_index 0, ip6_table_index 0, l2_table_index 0
>>> rule 0: ipv4 action 0 ip 0.0.0.0/0 mac 00:00:00:00:00:00 mask 
>>> 00:00:00:00:00:00
>>> 
>>> Notice that the ip4_table_index has changed from 3 in the first two 'show'
>>> command outputs, while it is now 0 in the 3rd 'show' output.
>>> 
>>> My guess is it should be a consistent value throughout, and I think it 
>>> should
>>> be table 3, but I'm not certain yet.
>>> 
>>> When I then go to remove the MACIP from the interface, I am told error -65,
>>> which is "No such table."
>>> 
>>> Should it have copied the ip4_table_index 3 to the replaced MACIP as it 
>>> stands
>>> after the macip_add_replace API call?
>>> 
>>> Or should the original MACIP ACL have inherited the table number 0 from the
>>> interface when it was first bound there?
> 
> Sorry.  I also hate gmail.  But I could digress acerbically.
> 
> Anyway.
> 
> I meant to say that I've read enough to know now that these are classifier
> table indices.  Which means the 3rd, unlisted option is more likely here:
> As the ACL changed, update these table to use the _new_ classifier table
> indices.  That should likely be table 4 unless the classifier can positively
> determine that there are no other users of tables 3 and can do it in place,
> in which case 3 is the correct answer.
> 
> But not 0.
> 
> Thanks,
> jdl
> 
> ___
> vpp-dev mailing list
> vpp-dev@lists.fd.io
> https://lists.fd.io/mailman/listinfo/vpp-dev
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] MACIP ACL replace causes ip4_table_index change?

[Jon Loeliger]

On Fri, Dec 8, 2017 at 11:24 AM, Jon Loeliger  wrote:

> On Fri, Dec 8, 2017 at 10:56 AM, Jon Loeliger  wrote:
>
>>
>> vpp# show acl-plugin macip acl
>> MACIP acl_index: 0, count: 1 (true len 1) tag {bob} is free pool slot: 0
>>   ip4_table_index 0, ip6_table_index 0, l2_table_index 0
>> rule 0: ipv4 action 0 ip 0.0.0.0/0 mac 00:00:00:00:00:00 mask
>> 00:00:00:00:00:00
>>
>> Notice that the ip4_table_index has changed from 3 in the first two 'show'
>> command outputs, while it is now 0 in the 3rd 'show' output.
>>
>> My guess is it should be a consistent value throughout, and I think it
>> should
>> be table 3, but I'm not certain yet.
>>
>> When I then go to remove the MACIP from the interface, I am told error
>> -65,
>> which is "No such table."
>>
>> Should it have copied the ip4_table_index 3 to the replaced MACIP as it
>> stands
>> after the macip_add_replace API call?
>>
>> Or should the original MACIP ACL have inherited the table number 0 from
>> the
>> interface when it was first bound there?
>>
>
Sorry.  I also hate gmail.  But I could digress acerbically.

Anyway.

I meant to say that I've read enough to know now that these are classifier
table indices.  Which means the 3rd, unlisted option is more likely here:
As the ACL changed, update these table to use the _new_ classifier table
indices.  That should likely be table 4 unless the classifier can positively
determine that there are no other users of tables 3 and can do it in place,
in which case 3 is the correct answer.

But not 0.

Thanks,
jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] MACIP ACL replace causes ip4_table_index change?

[Jon Loeliger]

On Fri, Dec 8, 2017 at 10:56 AM, Jon Loeliger  wrote:

>
> vpp# show acl-plugin macip acl
> MACIP acl_index: 0, count: 1 (true len 1) tag {bob} is free pool slot: 0
>   ip4_table_index 0, ip6_table_index 0, l2_table_index 0
> rule 0: ipv4 action 0 ip 0.0.0.0/0 mac 00:00:00:00:00:00 mask
> 00:00:00:00:00:00
>
> Notice that the ip4_table_index has changed from 3 in the first two 'show'
> command outputs, while it is now 0 in the 3rd 'show' output.
>
> My guess is it should be a consistent value throughout, and I think it
> should
> be table 3, but I'm not certain yet.
>
> When I then go to remove the MACIP from the interface, I am told error -65,
> which is "No such table."
>
> So.
>
> Should it have copied the ip4_table_index 3 to the replaced MACIP as it
> stands
> after the macip_add_replace API call?
>
> Or should the original MACIP ACL have inherited the table number 0 from the
> interface when it was first bound there?
>
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] MACIP ACL replace causes ip4_table_index change?

[Jon Loeliger]

Hey VPP Fans,

I've detected a slight anomaly in the handling of MACIP ACLs, and
would like some help tracking down the right solution.

I start by making a MACIP ACL. vppctl shows:

vpp# show acl-plugin macip acl
MACIP acl_index: 0, count: 1 (true len 1) tag {bob} is free pool slot: 0
  ip4_table_index 3, ip6_table_index 3, l2_table_index 3
rule 0: ipv4 action 1 ip 0.0.0.0/0 mac 00:00:00:00:00:00 mask
00:00:00:00:00:00

I then attach that to an interface, and vppctl still shows:

vpp# show acl-plugin macip acl
MACIP acl_index: 0, count: 1 (true len 1) tag {bob} is free pool slot: 0
  ip4_table_index 3, ip6_table_index 3, l2_table_index 3
rule 0: ipv4 action 1 ip 0.0.0.0/0 mac 00:00:00:00:00:00 mask
00:00:00:00:00:00

Then, I change the MACIP rule from permit to deny using the
API call macip_acl_add_replace to adjust it in-place.  Now vppctl shows:

vpp# show acl-plugin macip acl
MACIP acl_index: 0, count: 1 (true len 1) tag {bob} is free pool slot: 0
  ip4_table_index 0, ip6_table_index 0, l2_table_index 0
rule 0: ipv4 action 0 ip 0.0.0.0/0 mac 00:00:00:00:00:00 mask
00:00:00:00:00:00

Notice that the ip4_table_index has changed from 3 in the first two 'show'
command outputs, while it is now 0 in the 3rd 'show' output.

My guess is it should be a consistent value throughout, and I think it
should
be table 3, but I'm not certain yet.

When I then go to remove the MACIP from the interface, I am told error -65,
which is "No such table."

So.

Should it have copied the ip4_table_index 3 to the replaced MACIP as it
stands
after the macip_add_replace API call?

Or should the original MACIP ACL have inherited the table number 0 from the
interface when it was first bound there?

Given that the complaint (upon deletion) is about table 0 being invalid (as
it should
because that table is "permanently present", right?), I suspect that it
should have
copied the 3 to the new (after replacement) MACIP.

I'll go digging some more, but thought I'd just throw this out there in case
anyone knows better or more than I.

Thanks,
jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Build error when trying to cross-compile vpp

[Dave Barach (dbarach)]

Please try this sequence from the top of your workspace:

$ make bootstrap
$ make PLATFORM= build

That’s the “supported, plan-A” scheme. If it doesn’t work, please let us know.

If you specify PLATFORM when building host tools (i.e. vppapigen), it won’t 
work.

Thanks… Dave

From: nikhil ap [mailto:niks3...@gmail.com]
Sent: Thursday, December 7, 2017 10:58 PM
To: Dave Barach (dbarach) 
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Build error when trying to cross-compile vpp

Hi Dave,

It works if I run, "make is_build_tool=yes tools-install" in .../build-root but 
if I specify the platform, I still see the same issue if I try to cross-compile 
tools with  make PLATFORM=x86_64 TAG=x86_64_debug is_build_tool=yes 
tools-install

It is hitting this configuration in ../src/configure.ac

AM_COND_IF([CROSSCOMPILE],
[
  AC_PATH_PROG([VPPAPIGEN], [vppapigen], [no])
  if test "$VPPAPIGEN" = "no"; then
AC_MSG_ERROR([Externaly built vppapigen is needed when cross-compiling...])
  fi
],[


On Tue, Dec 5, 2017 at 8:53 PM, Dave Barach (dbarach) 
mailto:dbar...@cisco.com>> wrote:
See also “bootstrap.sh...”

$ make V=0 is_build_tool=yes tools-install

Thanks… Dave

From: nikhil ap [mailto:niks3...@gmail.com]
Sent: Tuesday, December 5, 2017 9:11 AM
To: Dave Barach (dbarach) mailto:dbar...@cisco.com>>
Cc: vpp-dev@lists.fd.io

Subject: Re: [vpp-dev] Build error when trying to cross-compile vpp

Hi Dave,

I added a file x86_64.mk in .../build-data/plaforms/ with the 
following content:

x86_64_arch = x86_64
x86_64_os = rumprun-netbsd
x86_64_target = x86_64-rumprun-netbsd
x86_64_native_tools = vppapigen
x86_64_uses_dpdk = yes

and in the TLD I did a "make PLATFORM=x86_64 TAG=x86_64_debug bootstrap" but I 
am still seeing that vppapigen is not getting built. Any clues?

Thanks,
Nikhil


On Tue, Dec 5, 2017 at 7:05 PM, Dave Barach (dbarach) 
mailto:dbar...@cisco.com>> wrote:
Dear Nikhil,

The first step in adding a new platform: construct 
.../build-data/plaforms/xxx.mk. There are several examples.

Note the rule:

xxx_native_tools = vppapigen

This rule builds the missing build-host tool.

Then:

“make PLATFORM=xxx TAG=xxx_debug vpp-install” or similar.

Caveat: the main Makefile “.../build-root/Makefile” is non-trivial.

In the past, we’ve used it to self-compile full toolchains, and to use the 
resulting toolchains to cross-compile embedded Linux images with squashfs / 
unionfs disk images.

All of the mechanisms are there to do interesting things, but since we seldom 
do those things anymore you can expect a certain amount of trouble.

Thanks… Dave

From: vpp-dev-boun...@lists.fd.io 
[mailto:vpp-dev-boun...@lists.fd.io] On 
Behalf Of nikhil ap
Sent: Tuesday, December 5, 2017 6:05 AM
To: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Build error when trying to cross-compile vpp

After a bit more digging around the make file, I did this:

 make PLATFORM=x86_64 x86_64_os=rumprun-netbsd bootstrap

checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-rumprun-netbsd
checking whether we are cross compiling... yes

However, I am still seeing this error:

checking for vppapigen... no
configure: error: Externaly built vppapigen is needed when cross-compiling...
Makefile:635: recipe for target 'tools-configure' failed
make[1]: *** [tools-configure] Error 1

What is the issue?

On Tue, Dec 5, 2017 at 3:55 PM, nikhil ap 
mailto:niks3...@gmail.com>> wrote:
Hi All,

I am trying to cross-compile vpp. The make doesn't expose a way to pass the 
--host parameter required to configure and build using cross compilation.

Initially, I did the following:

CC=x86_64-rumprun-netbsd-gcc make bootstrap, but I saw the following error

If you meant to cross compile, use `--host'.
See `config.log' for more details

As a work-around based on the config.log, I did this following

/src/configure (Stripped other output ) --build=x86_64-linux-gnu 
--host=x86_64-rumprun-netbsd --target=x86_64-linux-gnu

However,  I saw the following error:
checking for vppapigen... no
configure: error: Externaly built vppapigen is needed when cross-compiling...

Is there a way to cleanly cross-compile?


--
Regards,
Nikhil



--
Regards,
Nikhil



--
Regards,
Nikhil



--
Regards,
Nikhil
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] The feasibility of C++ gRPC with libvcl_ldpreload

[Keith Burns]

Ack, thanks Peter!

On Dec 8, 2017 2:48 AM, "Peter Palmár"  wrote:

> Hi Keith,
>
>
> thanks for your mail. I have just encountered something and therefore
> created this report:
>
> https://jira.fd.io/browse/VPP-1089
>
> VCL-LDPRELOAD: setsockopt(fd, SOL_SOCKET, SO_REUSEADDR, ...) does nothing,
> therefore, getsockopt(...) does not confirm an expected change
>
>
> Regards,
>
> Peter
> --
> *Od:* Keith Burns 
> *Odoslané:* štvrtok, 7. decembra 2017 16:05:39
> *Komu:* Peter Palmár
> *Kópia:* vpp-dev
> *Predmet:* Re: [vpp-dev] The feasibility of C++ gRPC with libvcl_ldpreload
>
> Peter,
>
> As you might be aware we've been focused on showcasing VPP integrated with
> the Ligato project for KubeCon this week.
>
> Once folks are back next week there's quite a bit of technical debt we
> need to address.
>
> There's also interest from other parties to use LIBVCL (not LDP per se),
> and I suspect after KubeCon sparks some interest there'll be more requests.
>
> I'm thinking the smartest way forward is to manage this via JIRA.
>
> If you could raise a feature request and assign it to me, we can then put
> everything in one place and prioritise/have a repository for folks who want
> to help to pick up tasks.
>
> On Dec 6, 2017 12:25 PM, "Peter Palmár" 
> wrote:
>
>> Hi,
>>
>> we are testing the VPP TCP stack by using the following combination: A
>> C++ application based on C++ gRPC with libvcl_ldpreload.
>>
>> We use greeter_server and greeter_client from
>> grpc/examples/cpp/helloworld taken from https://github.com/grpc/grpc.
>>
>> The server and client use the eventfd()/eventfd2() system call which is
>> not implemented in libvcl_ldpreload;
>> this seems to be a reason why the communication between the server and
>> client does not work.
>>
>> Could you please let me know whether I am right and if so, whether/when
>> an implementation of eventfd is planned to be added to libvcl_ldpreload?
>>
>> The attached file contains the client output.
>>
>> Regards,
>> Peter
>>
>>
>> ___
>> vpp-dev mailing list
>> vpp-dev@lists.fd.io
>> https://lists.fd.io/mailman/listinfo/vpp-dev
>>
>
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] The feasibility of C++ gRPC with libvcl_ldpreload

[Peter Palmár]

Hi Keith,


thanks for your mail. I have just encountered something and therefore created 
this report:

https://jira.fd.io/browse/VPP-1089

VCL-LDPRELOAD: setsockopt(fd, SOL_SOCKET, SO_REUSEADDR, ...) does nothing, 
therefore, getsockopt(...) does not confirm an expected change


Regards,

Peter


Od: Keith Burns 
Odoslané: štvrtok, 7. decembra 2017 16:05:39
Komu: Peter Palmár
Kópia: vpp-dev
Predmet: Re: [vpp-dev] The feasibility of C++ gRPC with libvcl_ldpreload

Peter,

As you might be aware we've been focused on showcasing VPP integrated with the 
Ligato project for KubeCon this week.

Once folks are back next week there's quite a bit of technical debt we need to 
address.

There's also interest from other parties to use LIBVCL (not LDP per se), and I 
suspect after KubeCon sparks some interest there'll be more requests.

I'm thinking the smartest way forward is to manage this via JIRA.

If you could raise a feature request and assign it to me, we can then put 
everything in one place and prioritise/have a repository for folks who want to 
help to pick up tasks.

On Dec 6, 2017 12:25 PM, "Peter Palmár"  wrote:
Hi,

we are testing the VPP TCP stack by using the following combination: A C++ 
application based on C++ gRPC with libvcl_ldpreload.

We use greeter_server and greeter_client from grpc/examples/cpp/helloworld 
taken from https://github.com/grpc/grpc.

The server and client use the eventfd()/eventfd2() system call which is not 
implemented in libvcl_ldpreload;
this seems to be a reason why the communication between the server and client 
does not work.

Could you please let me know whether I am right and if so, whether/when an 
implementation of eventfd is planned to be added to libvcl_ldpreload?

The attached file contains the client output.

Regards,
Peter


___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] how to redirect data?

[lin huang]

Hi, all

I want the data received by host-vpp1_inside port to redirect to port 
host-vpp2_inside. How can do it? Do I need to modify the code or adding a 
simple route rule??

Show int
host-vpp2_inside   2 up
host-vpp1_inside   1 up rx packets  
  1124
  rx bytes  
  48519
  drops 
  1124
  ip4   
 6
show int addr
host-vpp2_inside (up):
host-vpp1_inside (up):
  10.10.1.2/24

Show ip fib
10.10.1.2/32
  unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:12 buckets:1 uRPF:13 to:[0:0]]
[0] [@2]: dpo-receive: 10.10.1.2 on host-vpp1_inside


Thank you
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev