Re: [vpp-dev] QinQ and dot1ad any

[John Lo (loj) via Lists.Fd.Io]

Hi Jon,

You are right on both counts.  It is the combination of dot1q/ad-any and 
exact-match that we should reject.  It is also correct the check should be at 
lower level to reject the combination for both API and CLI.

Regards,
John

From: Jon Loeliger 
Sent: Wednesday, December 18, 2019 11:48 AM
To: John Lo (loj) 
Cc: Raj ; vpp-dev 
Subject: Re: [vpp-dev] QinQ and dot1ad any

On Tue, Dec 17, 2019 at 8:13 AM John Lo (loj) via 
Lists.Fd.Io 
mailto:cisco@lists.fd.io>> wrote:

Thus, sub-interface with "inner-dot1q any" is not an exact match sub-interface 
by definition since no match is present on inner tag.

I suppose the CLI:
>> create sub-interfaces GigabitEthernet3/0/3 50 dot1ad 50 inner-dot1q any 
>> exact-match
should have been rejected as exact match cannot be supported on the 
sub-interface.  This is something we should ideally fix in the CLI to avoid any 
confusion with the meaning of exact match.

Regards,
John

Hi John,

I have two questions here.  First, a clarification on what combinations of 
options
should be rejected.  Are you saying that the pair "inner-dot1q any" should be 
rejected,
or are you saying the trio "inner-do1q any exact match" should be rejected.  I 
suspect
you are meaning the latter.

Second, while rejecting it in the CLI would be nice, that would still allow the 
configuration
via the API, right?  So it might be better to reject it one layer down so it is 
caught by
both the CLI and the API.

Thanks,
jdl

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#14924): https://lists.fd.io/g/vpp-dev/message/14924
Mute This Topic: https://lists.fd.io/mt/68757125/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] QinQ and dot1ad any

[John Lo (loj) via Lists.Fd.Io]

I don't think 8-10 S-VLANs with 4K C-VLANs totaling ~40K sub-interfaces will be 
an issue for VPP to handle, as long as the NICs being polled by device-input 
node from DPDK or other device drivers are not at a large scale.



I am not clear what was done with PPPoE to address similar issues. I suppose 
VPP can in theory be enhanced to support IP forwarding on "inner dot1q any" 
sub-interfaces as follows:

  *   All ARP entries for output IP addresses on that sub-interface must be 
statically provisioned by control plane via API or user CLI. This means the set 
IP ARP CLI/API needs to be enhanced to specify what are the inner VLAN tag to 
use for ARP entry.
  *   The handling of glean adjacency for any IP address using this 
sub-interface without ARP entry should probably be changed to not sent any ARP 
requests.
  *   We also need to enhance VPP's arp-request handling on that sub-interface 
so the VLAN tags are preserved on arp-response.  Or alternatively, require any 
neighbor of the sub-interface to have ARP entries provisioned so it won’t sent 
ARP requests.



I am not sure how much work will be involved in doing this, or if there is any 
other changes I may have missed.



Regards,

John



-Original Message-

From: vpp-dev@lists.fd.io  On Behalf Of Raj

Sent: Wednesday, December 18, 2019 8:32 AM

To: vpp-dev 

Subject: Re: [vpp-dev] QinQ and dot1ad any



On Tue, Dec 17, 2019 at 7:43 PM John Lo (loj)  wrote:



> Without exact match on a L3 sub-interface, VPP has no mechanism to

> know what VLAN tags to use for packet output, such as ARP request packets or 
> IP packets, on that sub-interface.



For a big QinQ network (like say about 8 - 10 S-VLAN each with 4K

C-VLANs) , the number of interface can become huge. Will that hit some internal 
VPP limits or will it become a performance problem?



Is it a good idea to have a mechanism to provide this information to VPP via a 
control plane application, like whats is being done for PPPoE, so that only 
outer VLAN interface needs to be created, while inner VLAN interface will be 
provided by the control plane application? Is this a road worth traveling?



Thanks and Regards,



Raj
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#14923): https://lists.fd.io/g/vpp-dev/message/14923
Mute This Topic: https://lists.fd.io/mt/68757125/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] 20.01: three weeks before the API freeze

[Andrew Yourtchenko]

Hello all,

It's again the time of the year, to begin the preparations for 20.01
VPP release.

According to the agreed release plan [1], the API freeze will happen
on the January 8 2020, at 18:00 UTC,
so this is a first gentle reminder three weeks in advance.

As usual - feel free to update the release plan wiki page with the
features that you are working on for that release.

[1] https://wiki.fd.io/view/Projects/vpp/Release_Plans/Release_Plan_20.01

--a
-- Your friendly 20.01 release manager
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#14922): https://lists.fd.io/g/vpp-dev/message/14922
Mute This Topic: https://lists.fd.io/mt/68800646/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] QinQ and dot1ad any

[Jon Loeliger via Lists.Fd.Io]

On Tue, Dec 17, 2019 at 8:13 AM John Lo (loj) via Lists.Fd.Io  wrote:

>
> Thus, sub-interface with "inner-dot1q any" is not an exact match
> sub-interface by definition since no match is present on inner tag.
>
> I suppose the CLI:
> >> create sub-interfaces GigabitEthernet3/0/3 50 dot1ad 50 inner-dot1q any
> exact-match
> should have been rejected as exact match cannot be supported on the
> sub-interface.  This is something we should ideally fix in the CLI to avoid
> any confusion with the meaning of exact match.
>
> Regards,
> John
>

Hi John,

I have two questions here.  First, a clarification on what combinations of
options
should be rejected.  Are you saying that the pair "inner-dot1q any"
should be rejected,
or are you saying the trio "inner-do1q any exact match" should be
rejected.  I suspect
you are meaning the latter.

Second, while rejecting it in the CLI would be nice, that would still
allow the configuration
via the API, right?  So it might be better to reject it one layer down so
it is caught by
both the CLI and the API.

Thanks,
jdl
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#14921): https://lists.fd.io/g/vpp-dev/message/14921
Mute This Topic: https://lists.fd.io/mt/68757125/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] thread context per node

[amitmulayoff]

Hello guys

I have a question regarding thread context.

I have a node that uses the function “vlib_put_frame_to_node()” to “move” the 
frame forward to the next node.
My problem is that I want it to run in a context of worker thread instead of 
the main_vpp thread.

Can I run the whole node in a context of worker thread or can I dispatch the 
frame next

To the worker thread to handle?
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#14920): https://lists.fd.io/g/vpp-dev/message/14920
Mute This Topic: https://lists.fd.io/mt/68797792/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] Coverity run FAILED as of 2019-12-18 14:03:39 UTC

[Noreply Jenkins]

Coverity run failed today.

Current number of outstanding issues are 2
Newly detected: 0
Eliminated: 0
More details can be found at  
https://scan.coverity.com/projects/fd-io-vpp/view_defects
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#14919): https://lists.fd.io/g/vpp-dev/message/14919
Mute This Topic: https://lists.fd.io/mt/68795869/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] QinQ and dot1ad any

[Raj]

On Tue, Dec 17, 2019 at 7:43 PM John Lo (loj)  wrote:

> Without exact match on a L3 sub-interface, VPP has no mechanism to know what 
> VLAN tags
> to use for packet output, such as ARP request packets or IP packets, on that 
> sub-interface.

For a big QinQ network (like say about 8 - 10 S-VLAN each with 4K
C-VLANs) , the number of interface can become huge. Will that hit some
internal VPP limits or will it become a performance problem?

Is it a good idea to have a mechanism to provide this information to
VPP via a control plane application, like whats is being done for
PPPoE, so that only outer VLAN interface needs to be created, while
inner VLAN interface will be provided by the control plane
application? Is this a road worth traveling?

Thanks and Regards,

Raj
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#14918): https://lists.fd.io/g/vpp-dev/message/14918
Mute This Topic: https://lists.fd.io/mt/68757125/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-