PSL inline vs pipeline?

[HeikoAnkenbrand]

Where can I find a R81.10 documentation on what exactly is the difference between PSL inline and PSL pipeline?

[Timothy_Hall]

I don't believe these are documented anywhere, but I think the inline path is only used if a Falcon accelerator card is present; that traffic was handled "inline" by the Falcon card between NIC ports.

The pipeline paths are Check Point's answer to the elephant flow issue of saturating a single core, and is the new feature I was alluding to at the end of my CPX speech on elephant flows.  The pipeline paths first appeared in a Jumbo HFA of R80.40 but were not enabled by default.  The pipeline paths are enabled by default in R81.10 (not sure about R81) and allow the processing of a single connection's packets to be spread across a limited number of worker cores (3 I think).  Not sure if this is only invoked when a worker hits 100% kind of like Priority Queues.

[HeikoAnkenbrand]

Hi @Timothy_Hall,

I had already written an article on Falcon Cards "R8x - Security Gateway Architecture (Acceleration Card Offloading)".

Then the PSL inline path must be the "Inline path"???
Then the PSL pipeline must be the "Buffer path" or "Host path"
or "the pipeline paths are Check Point's answer to the elephant flow issue" that you describe???

I don't really understand it.

Can someone from Check Point R&D please answer this.
So that we get a 100% correct statement.

--------------------------------------------------------------------------------------------------------

Here are the paths to the Falcon Cards:

R80.20+ acceleration cards provide three new acceleration flows:

•         Host path
•         Buffer path
•         Inline path

Inline path - For HTTP response body (until 1^st tier match) and TLS bulk encryption/ decryption.

Buffer path - For HTTP requests, HTTP response headers and TLS handshakes.



Host Path - For non acceleration connections (eg. local connections) and connections on non acceleration card interface.

[Timothy_Hall]

Yeah we need a clarification from R&D on this one.  In the meantime I forgot to add that the inline paths seem to be part of the MUX feature described in this thread:

https://community.checkpoint.com/t5/Security-Gateways/What-does-mux-enabled-kernel-parameter-do-exac...

[udo_kimmich]

Information from R&D would be very helpful here.
No one understands the paths any more!

[HeikoAnkenbrand]

Any news from Check Point to this topic?

[PhoneBoy]

@idants Do you happen to know what these are?

[idants]

I moved to a new position since then.

Please take it with Chen Muchtar.

[PhoneBoy]

Sorry about that.
@Chen_Muchtar ?

[Chen_Muchtar · Accepted solution]

Hi,

• The statistics you’re referring to counts the number of packets passing through the different available packet flows in a Check Point GW
• SK153832 currently lists the following paths: Firewall path / Slow path (F2F), Medium path (PXL) and Accelerated path
• On top of that, we have Pipeline processing path – a connection which is handled by more than one CPU (unlike in other paths in which a connection is handled by a dedicated CPU)
• Would be updated in SK153832 by EOW
• Preparations for this infra were first introduced over R80.40
• The project is targeted for R81.20 (would be also ported to several JHFs), its main goal is to allow better utilization of the systems resources to tackle elephant flows scenarios in NGTP env. at first stage (content would be expanding over future releases)
• Project is due to start EA phase soon (+ dedicated RnD support), feel free to refer me offline per relevant customers/ EA candidates
• Addressing additional Qs which were raised over this thread:
• “PSL pipeline” refers to packets passing through Pipeline processing path (mentioned above) and handled by PSL
• Until the project release, it will always show as 0
• “PSL inline” refers to the legacy Falcon Cards
• This flow is deprecated and the statistics will be removed in R81.20 and JHFs
• This stat will always show as 0 as well

 All, you're always welcome to approach me on any related matter @ [email protected]

[Timothy_Hall]

Great explanation, glad to see I was pretty close in my earlier post.  Thanks!

[_Val_]

I guess we need a TechTalk about it, @Chen_Muchtar 

[Don_Paterson]

Did a TechTalk on this happen?

Seems like a good time to do one now, with R81.20 release coming   🙂

[_Val_]

No, we are still trying to convince Chen 🙂