Re: [dpdk-users] [dpdk-dev] Sharing of pipelines in IP_PIPELINE application

["Dumitrescu, Cristian" <cristian.dumitrescu@intel.com>]

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Nidhia Varghese
> Sent: Wednesday, July 5, 2017 10:44 AM
> To: dev@dpdk.org; users@dpdk.org
> Subject: [dpdk-dev] Sharing of pipelines in IP_PIPELINE application
> 
> Hi,
> 
> I want to create a Mac-Learning pipeline application where upstream learns
> the incoming source mac and incoming port. For downstream I have to
> forward
> the traffic based on this mac-learning table created during the upstream.
> My idea is:
> 
>    - Share the mac-learning pipeline between upstream and downstream
>    communication. (ie., use the same pipeline for US and DS)  Thus I will be
>    able to use the same mac-learning table for both upstream and
> downstream.
> 
> Is it possible to do so? Or is there any other way to use the mac-learning
> table in a shared manner?
> 
> Thanks for your reply and help.
> 
> Regards,
> Nidhia Varghese

Hi Nidhia,

Is the upstream processing very different than downstream processing, or is the functional difference limited to different configuration (e.g. MAC address, IP address, etc) of same functionality?

Assuming same/similar functionality (e.g. L2 bridging):
-it makes sense to design a  single pipeline type to handling both upstream and downstream
-the U and D ports are all input ports in the same pipeline
-the learning is simply an action (input port or table action) executed as part of the packet reception: it simply adds a new entry (if not already present) to the forwarding table
-where there is learning, there is probably aging as well, which could be a request coming from control plane:
	-CP can maintain its own copy of the forwarding table (so CP has to be notified by learning events)
	-periodically, CP can examine a set of N entries and check if any needs to be purged: if yes, send a request to DP to purge that entry from its forwarding table

Assuming different functionality (e.g. edge router):
-it makes sense to design two different pipeline types, one for U and one for D
-typically, the NICs that are U input ports serve as the D output ports, the other NICs that are D input ports serve as the U output ports
-in this case, probably the U learning action is to notify the CP of a learning event, which CP then translates into a request to D to add a new entry to its forwarding table

Note that, as we discussed in other threads, we avoid directly sharing the same table between two pipelines, which can run on different CPU cores:
- Each pipeline owns its tables (only one table writer and reader)
	-This way, we avoid concurrency issues: locks per table or table entry => performance issue
	-This way, we avoid the ping-pong of cache lines between CPU cores => performance issue
-If need be, the same table is replicated to multiple DP pipeline instances rather than share the same table (for the above reasons)
	-All the table instances are kept in-sync by the CP

Regards,
Cristian