PF_RING: Include in main line kernel?

PF_RING: Include in main line kernel?

[Brad Doctor]

Greetings,

On behalf of the users and developers of the PF_RING project, we would
like to ask consideration to include the PF_RING module in the main
line kernel.

PF_RING (http://www.ntop.org/PF_RING.html) is a kernel module that
implements an mmap()-ed memory ring for accelerating packet capture
and for providing all the basic features a network monitoring
application needs. PF_RING includes several features such as packet
filtering, balancing across capture applications, packet reflection
(i.e. capture application can decide to bounce selected packets onto
an as-specified interface). Packets are filtered both using BPF and
using ACL-like rules (e.g. tcp and ports from 80 to 100). Using
PF_RING it is also possible to exploit multiple RX queues provided by
modern NIC adapters. PF_RING achieves a significant speedup by making
only one copy of the packet. Additionally, PF_RING is able to operate
in a capture-only installation, further increasing performance.

PF_RING has been around since 2003 and is very mature with an active
contributing developer base. The developer and user community use a
mailing list (http://listgateway.unipi.it/pipermail/ntop-misc/) for
discussions and submissions. PF_RING is used in several projects,
ranging from distributions such as DD-WRT/OpenWrt to improving
performance of applications like Snort and Wireshark. Many commercial
companies around the world in the field of intrusion detection and
traffic analysis rely on PF_RING for accelerating their products and
operations.

The PF_RING module relies on a small patch to net/core/dev.c that
intercepts when a packet is received/transmitted so that it can be
passed to the PF_RING module when present and with an active listener.
Other than these minor changes, all the PF_RING code is
self-contained, comprising jut two files: ring.c and ring.h. PF_RING
is the result of many years of research and development specifically
into high-speed packet capture, and is homegrown. PF_RING uses the
stock GPL license.

We feel that PF_RING is ready to be included with the mainline kernel.
We are ready and eager to support PF_RING for the long term.

Thank you in advance for your consideration!

-brad

Re: PF_RING: Include in main line kernel?

[Stephen Hemminger]

On Wed, 14 Oct 2009 08:33:08 -0600
Brad Doctor <brad.doctor@gmail.com> wrote:

> Greetings,
> 
> On behalf of the users and developers of the PF_RING project, we would
> like to ask consideration to include the PF_RING module in the main
> line kernel.
> 
> PF_RING (http://www.ntop.org/PF_RING.html) is a kernel module that
> implements an mmap()-ed memory ring for accelerating packet capture
> and for providing all the basic features a network monitoring
> application needs. PF_RING includes several features such as packet
> filtering, balancing across capture applications, packet reflection
> (i.e. capture application can decide to bounce selected packets onto
> an as-specified interface). Packets are filtered both using BPF and
> using ACL-like rules (e.g. tcp and ports from 80 to 100). Using
> PF_RING it is also possible to exploit multiple RX queues provided by
> modern NIC adapters. PF_RING achieves a significant speedup by making
> only one copy of the packet. Additionally, PF_RING is able to operate
> in a capture-only installation, further increasing performance.
> 
> PF_RING has been around since 2003 and is very mature with an active
> contributing developer base. The developer and user community use a
> mailing list (http://listgateway.unipi.it/pipermail/ntop-misc/) for
> discussions and submissions. PF_RING is used in several projects,
> ranging from distributions such as DD-WRT/OpenWrt to improving
> performance of applications like Snort and Wireshark. Many commercial
> companies around the world in the field of intrusion detection and
> traffic analysis rely on PF_RING for accelerating their products and
> operations.
> 
> The PF_RING module relies on a small patch to net/core/dev.c that
> intercepts when a packet is received/transmitted so that it can be
> passed to the PF_RING module when present and with an active listener.
> Other than these minor changes, all the PF_RING code is
> self-contained, comprising jut two files: ring.c and ring.h. PF_RING
> is the result of many years of research and development specifically
> into high-speed packet capture, and is homegrown. PF_RING uses the
> stock GPL license.
> 
> We feel that PF_RING is ready to be included with the mainline kernel.
> We are ready and eager to support PF_RING for the long term.
> 
> Thank you in advance for your consideration!

I was going to wrap pfring up for the staging tree.
The code you put in network receive path is not necessary;
it would be cleaner to just use existing packet type all hook, and
then PF_RING could be a loadable module without having to be compiled in.

-- 

Re: PF_RING: Include in main line kernel?

[Jarek Poplawski]

Brad Doctor wrote, On 10/14/2009 04:33 PM:

> into high-speed packet capture, and is homegrown. PF_RING uses the
> stock GPL license.


Are you sure you're using the stock GNU GPL?:

> Download ntop
> 
> ntop is distributed under the GNU GPL. In order to be entitled to download ntop you must accept the GNU license. 

I can't find such a thing neither in GNU GPL v2:

"5.  You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Program (or any work based on the Program), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Program or works based on it. "

nor in GNU GPL v3:

"9. Acceptance Not Required for Having Copies.

You are not required to accept this License in order to receive or run a copy of the Program. Ancillary propagation of a covered work occurring solely as a consequence of using peer-to-peer transmission to receive a copy likewise does not require acceptance. However, nothing other than this License grants you permission to propagate or modify any covered work. These actions infringe copyright if you do not accept this License. Therefore, by modifying or propagating a covered work, you indicate your acceptance of this License to do so."

Thanks,
Jarek P.

Re: PF_RING: Include in main line kernel?

[Brad Doctor]

This is for ntop, which uses PF_RING, but is a traffic analysis
application and is separate.

But you raise a good point and we will make the change for ntop.

thanks!
-brad

On Wed, Oct 14, 2009 at 10:46 AM, Jarek Poplawski <jarkao2@gmail.com> wrote:
> Brad Doctor wrote, On 10/14/2009 04:33 PM:
>
>> into high-speed packet capture, and is homegrown. PF_RING uses the
>> stock GPL license.
>
>
> Are you sure you're using the stock GNU GPL?:
>
>> Download ntop
>>
>> ntop is distributed under the GNU GPL. In order to be entitled to download ntop you must accept the GNU license.
>
> I can't find such a thing neither in GNU GPL v2:
>
> "5.  You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Program (or any work based on the Program), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Program or works based on it. "
>
> nor in GNU GPL v3:
>
> "9. Acceptance Not Required for Having Copies.
>
> You are not required to accept this License in order to receive or run a copy of the Program. Ancillary propagation of a covered work occurring solely as a consequence of using peer-to-peer transmission to receive a copy likewise does not require acceptance. However, nothing other than this License grants you permission to propagate or modify any covered work. These actions infringe copyright if you do not accept this License. Therefore, by modifying or propagating a covered work, you indicate your acceptance of this License to do so."
>
> Thanks,
> Jarek P.
>

Re: PF_RING: Include in main line kernel?

[Brad Doctor]

Good point for sure. We will make the change and get back to you.
Thanks for the quick reply, we appreciate it very much!

-brad

On Wed, Oct 14, 2009 at 10:01 AM, Stephen Hemminger
<shemminger@vyatta.com> wrote:
> On Wed, 14 Oct 2009 08:33:08 -0600
> Brad Doctor <brad.doctor@gmail.com> wrote:
>
>> Greetings,
>>
>> On behalf of the users and developers of the PF_RING project, we would
>> like to ask consideration to include the PF_RING module in the main
>> line kernel.
>>
>> PF_RING (http://www.ntop.org/PF_RING.html) is a kernel module that
>> implements an mmap()-ed memory ring for accelerating packet capture
>> and for providing all the basic features a network monitoring
>> application needs. PF_RING includes several features such as packet
>> filtering, balancing across capture applications, packet reflection
>> (i.e. capture application can decide to bounce selected packets onto
>> an as-specified interface). Packets are filtered both using BPF and
>> using ACL-like rules (e.g. tcp and ports from 80 to 100). Using
>> PF_RING it is also possible to exploit multiple RX queues provided by
>> modern NIC adapters. PF_RING achieves a significant speedup by making
>> only one copy of the packet. Additionally, PF_RING is able to operate
>> in a capture-only installation, further increasing performance.
>>
>> PF_RING has been around since 2003 and is very mature with an active
>> contributing developer base. The developer and user community use a
>> mailing list (http://listgateway.unipi.it/pipermail/ntop-misc/) for
>> discussions and submissions. PF_RING is used in several projects,
>> ranging from distributions such as DD-WRT/OpenWrt to improving
>> performance of applications like Snort and Wireshark. Many commercial
>> companies around the world in the field of intrusion detection and
>> traffic analysis rely on PF_RING for accelerating their products and
>> operations.
>>
>> The PF_RING module relies on a small patch to net/core/dev.c that
>> intercepts when a packet is received/transmitted so that it can be
>> passed to the PF_RING module when present and with an active listener.
>> Other than these minor changes, all the PF_RING code is
>> self-contained, comprising jut two files: ring.c and ring.h. PF_RING
>> is the result of many years of research and development specifically
>> into high-speed packet capture, and is homegrown. PF_RING uses the
>> stock GPL license.
>>
>> We feel that PF_RING is ready to be included with the mainline kernel.
>> We are ready and eager to support PF_RING for the long term.
>>
>> Thank you in advance for your consideration!
>
> I was going to wrap pfring up for the staging tree.
> The code you put in network receive path is not necessary;
> it would be cleaner to just use existing packet type all hook, and
> then PF_RING could be a loadable module without having to be compiled in.
>
> --
>

Re: PF_RING: Include in main line kernel?

[Jarek Poplawski]

On Wed, Oct 14, 2009 at 11:02:01AM -0600, Brad Doctor wrote:
> This is for ntop, which uses PF_RING, but is a traffic analysis
> application and is separate.

For some strange reason I thought I could download PF_RING from the
download page too... (not for modifying or distributing! ;-)

Thanks,
Jarek P.

Re: PF_RING: Include in main line kernel?

[Brent Cook]

On Wednesday 14 October 2009 09:33:08 Brad Doctor wrote:
> Greetings,
> 
> On behalf of the users and developers of the PF_RING project, we would
> like to ask consideration to include the PF_RING module in the main
> line kernel.
> 
> PF_RING (http://www.ntop.org/PF_RING.html) is a kernel module that
> implements an mmap()-ed memory ring for accelerating packet capture
> and for providing all the basic features a network monitoring
> application needs. PF_RING includes several features such as packet
> filtering, balancing across capture applications, packet reflection
> (i.e. capture application can decide to bounce selected packets onto
> an as-specified interface). Packets are filtered both using BPF and
> using ACL-like rules (e.g. tcp and ports from 80 to 100). Using
> PF_RING it is also possible to exploit multiple RX queues provided by
> modern NIC adapters. PF_RING achieves a significant speedup by making
> only one copy of the packet. Additionally, PF_RING is able to operate
> in a capture-only installation, further increasing performance.

What is the difference between PF_RING and the existing
PACKET_RX_RING support (which is now complemented by PACKET_TX_RING). 

ggaoed makes use of both of these, though it is one of the few open-source projects I've found that do: http://code.google.com/p/ggaoed/

I've used PACKET_RX_RING with SO_ATTACH_FILTER to implement filtering via BPF code. You can also set PACKET_COPY_THRESH to filter on size, etc. Has anyone done a PF_RING/PACKET_RX_RING speed comparison? They seem feature-wise pretty similar.

> PF_RING has been around since 2003 and is very mature with an active
> contributing developer base. The developer and user community use a
> mailing list (http://listgateway.unipi.it/pipermail/ntop-misc/) for
> discussions and submissions. PF_RING is used in several projects,
> ranging from distributions such as DD-WRT/OpenWrt to improving
> performance of applications like Snort and Wireshark. Many commercial
> companies around the world in the field of intrusion detection and
> traffic analysis rely on PF_RING for accelerating their products and
> operations.
> 
> The PF_RING module relies on a small patch to net/core/dev.c that
> intercepts when a packet is received/transmitted so that it can be
> passed to the PF_RING module when present and with an active listener.
> Other than these minor changes, all the PF_RING code is
> self-contained, comprising jut two files: ring.c and ring.h. PF_RING
> is the result of many years of research and development specifically
> into high-speed packet capture, and is homegrown. PF_RING uses the
> stock GPL license.
> 
> We feel that PF_RING is ready to be included with the mainline kernel.
> We are ready and eager to support PF_RING for the long term.
> 
> Thank you in advance for your consideration!
> 
> -brad
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: PF_RING: Include in main line kernel?

[Stephen Hemminger]

On Wed, 14 Oct 2009 11:02:45 -0600
Brad Doctor <brad.doctor@gmail.com> wrote:

> Good point for sure. We will make the change and get back to you.
> Thanks for the quick reply, we appreciate it very much!
> 
> -brad
> 
> On Wed, Oct 14, 2009 at 10:01 AM, Stephen Hemminger
> <shemminger@vyatta.com> wrote:
> > On Wed, 14 Oct 2009 08:33:08 -0600
> > Brad Doctor <brad.doctor@gmail.com> wrote:
> >
> >> Greetings,
> >>
> >> On behalf of the users and developers of the PF_RING project, we would
> >> like to ask consideration to include the PF_RING module in the main
> >> line kernel.
> >>
> >> PF_RING (http://www.ntop.org/PF_RING.html) is a kernel module that
> >> implements an mmap()-ed memory ring for accelerating packet capture
> >> and for providing all the basic features a network monitoring
> >> application needs. PF_RING includes several features such as packet
> >> filtering, balancing across capture applications, packet reflection
> >> (i.e. capture application can decide to bounce selected packets onto
> >> an as-specified interface). Packets are filtered both using BPF and
> >> using ACL-like rules (e.g. tcp and ports from 80 to 100). Using
> >> PF_RING it is also possible to exploit multiple RX queues provided by
> >> modern NIC adapters. PF_RING achieves a significant speedup by making
> >> only one copy of the packet. Additionally, PF_RING is able to operate
> >> in a capture-only installation, further increasing performance.
> >>
> >> PF_RING has been around since 2003 and is very mature with an active
> >> contributing developer base. The developer and user community use a
> >> mailing list (http://listgateway.unipi.it/pipermail/ntop-misc/) for
> >> discussions and submissions. PF_RING is used in several projects,
> >> ranging from distributions such as DD-WRT/OpenWrt to improving
> >> performance of applications like Snort and Wireshark. Many commercial
> >> companies around the world in the field of intrusion detection and
> >> traffic analysis rely on PF_RING for accelerating their products and
> >> operations.
> >>
> >> The PF_RING module relies on a small patch to net/core/dev.c that
> >> intercepts when a packet is received/transmitted so that it can be
> >> passed to the PF_RING module when present and with an active listener.
> >> Other than these minor changes, all the PF_RING code is
> >> self-contained, comprising jut two files: ring.c and ring.h. PF_RING
> >> is the result of many years of research and development specifically
> >> into high-speed packet capture, and is homegrown. PF_RING uses the
> >> stock GPL license.
> >>
> >> We feel that PF_RING is ready to be included with the mainline kernel.
> >> We are ready and eager to support PF_RING for the long term.
> >>
> >> Thank you in advance for your consideration!
> >
> > I was going to wrap pfring up for the staging tree.
> > The code you put in network receive path is not necessary;
> > it would be cleaner to just use existing packet type all hook, and
> > then PF_RING could be a loadable module without having to be compiled in.
> >
> > --
> >

If you want, I'll try and do it. Are there any tests other
than just ntop?

Re: PF_RING: Include in main line kernel?

[Luca Deri]

Brent
contrary to other socket types, PF_RING allows
- packets to be filtered using both BPF and ACL-like filters
- parsing information is returned as metadata with the packet (i.e.  
you don't have to parse the packet again as it happens with BPF)
- ACL-like filters allows you to specify advanced features such as  
port ranges or packet payload match

I agree with you that PF_RING has some overlaps with PACKET_RX/ 
TX_RING, but the main idea behind PF_RING is not just to accelerate  
packet capture. For instance in PF_RING you can have actions attached  
to rules, or extend PF_RING filtering/packet handling by means of  
plugins.
For instance I have coded PF_RING plugins for parsing and filtering  
inside PF_RING protocols such as SIP, RTP, RTCP just to name a few  
that I would like to release after PF_RING kernel integration.

For all those who want to see what you can do with PF_RING, I suggest  
to read this tutorial: http://luca.ntop.org/MulticorePacketCapture.pdf

Regards Luca

PF_RING allows you to specify mutiple
On Oct 14, 2009, at 8:19 PM, Brent Cook wrote:

> On Wednesday 14 October 2009 09:33:08 Brad Doctor wrote:
>> Greetings,
>>
>> On behalf of the users and developers of the PF_RING project, we  
>> would
>> like to ask consideration to include the PF_RING module in the main
>> line kernel.
>>
>> PF_RING (http://www.ntop.org/PF_RING.html) is a kernel module that
>> implements an mmap()-ed memory ring for accelerating packet capture
>> and for providing all the basic features a network monitoring
>> application needs. PF_RING includes several features such as packet
>> filtering, balancing across capture applications, packet reflection
>> (i.e. capture application can decide to bounce selected packets onto
>> an as-specified interface). Packets are filtered both using BPF and
>> using ACL-like rules (e.g. tcp and ports from 80 to 100). Using
>> PF_RING it is also possible to exploit multiple RX queues provided by
>> modern NIC adapters. PF_RING achieves a significant speedup by making
>> only one copy of the packet. Additionally, PF_RING is able to operate
>> in a capture-only installation, further increasing performance.
>
> What is the difference between PF_RING and the existing
> PACKET_RX_RING support (which is now complemented by PACKET_TX_RING).
>
> ggaoed makes use of both of these, though it is one of the few open- 
> source projects I've found that do: http://code.google.com/p/ggaoed/
>
> I've used PACKET_RX_RING with SO_ATTACH_FILTER to implement  
> filtering via BPF code. You can also set PACKET_COPY_THRESH to  
> filter on size, etc. Has anyone done a PF_RING/PACKET_RX_RING speed  
> comparison? They seem feature-wise pretty similar.
>
>> PF_RING has been around since 2003 and is very mature with an active
>> contributing developer base. The developer and user community use a
>> mailing list (http://listgateway.unipi.it/pipermail/ntop-misc/) for
>> discussions and submissions. PF_RING is used in several projects,
>> ranging from distributions such as DD-WRT/OpenWrt to improving
>> performance of applications like Snort and Wireshark. Many commercial
>> companies around the world in the field of intrusion detection and
>> traffic analysis rely on PF_RING for accelerating their products and
>> operations.
>>
>> The PF_RING module relies on a small patch to net/core/dev.c that
>> intercepts when a packet is received/transmitted so that it can be
>> passed to the PF_RING module when present and with an active  
>> listener.
>> Other than these minor changes, all the PF_RING code is
>> self-contained, comprising jut two files: ring.c and ring.h. PF_RING
>> is the result of many years of research and development specifically
>> into high-speed packet capture, and is homegrown. PF_RING uses the
>> stock GPL license.
>>
>> We feel that PF_RING is ready to be included with the mainline  
>> kernel.
>> We are ready and eager to support PF_RING for the long term.
>>
>> Thank you in advance for your consideration!
>>
>> -brad
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>

Re: PF_RING: Include in main line kernel?

[David Miller]

From: Luca Deri <deri@ntop.org>
Date: Wed, 14 Oct 2009 21:54:26 +0200

> - packets to be filtered using both BPF and ACL-like filters

To me this is all that PF_RING adds, the ACL filter features.

And I see no reason why that can't be added to PF_PACKET, we've
extended PF_PACKET in many ways before (even the mmap ring
buffer layout can be modified trivially) so there is no reason
we can't add the ACL filter feature to PF_PACKET as well.

Adding all of PF_RING just for that is a joke.

Re: PF_RING: Include in main line kernel?

[Luca Deri]

Stephen
many thanks for your feedback I appreciated it.

The reason why I decided to patch dev.c is because I wanted PF_RING to  
decide whether the packet journey shall continue or not. In other  
words with my solution PF_RING applications can decide whether the  
received packets will also be delivered to upper layers (and to other  
kernel network components). This configurable 'early packet drop'  
allows the overall performance to be significantly increased as  
received packets are not supposed to be delivered to upper layers;  
this is a typical situations for many monitoring devices.

Another reason, is that having a hook in dev.c, device drivers can  
pass PF_RING packets directly without going through the standard  
kernel mechanisms. For instance I have developed some drivers that if  
they detect the presence of PF_RING, pass received packets directly to  
PF_RING instead of going with NAPI.

These are reasons behind my design choices. However if you believe  
that my arguments are not enough, and it's better to use a different  
approach, I'm prepared to change the implementation. Please let me  
know what you want me to change in order to include PF_RING into the  
kernel source tree.

If you want to test it, for your convenience I have created a patch  
for kernel 2.6.31.3:
https://svn.ntop.org/svn/ntop/trunk/PF_RING/patches/linux-2.6.31.3-1-686-smp-PF_RING.patch.gz

Regards Luca


On Oct 14, 2009, at 9:33 PM, Stephen Hemminger wrote:

> On Wed, 14 Oct 2009 11:02:45 -0600
> Brad Doctor <brad.doctor@gmail.com> wrote:
>
>> Good point for sure. We will make the change and get back to you.
>> Thanks for the quick reply, we appreciate it very much!
>>
>> -brad
>>
>> On Wed, Oct 14, 2009 at 10:01 AM, Stephen Hemminger
>> <shemminger@vyatta.com> wrote:
>>> On Wed, 14 Oct 2009 08:33:08 -0600
>>> Brad Doctor <brad.doctor@gmail.com> wrote:
>>>
>>>> Greetings,
>>>>
>>>> On behalf of the users and developers of the PF_RING project, we  
>>>> would
>>>> like to ask consideration to include the PF_RING module in the main
>>>> line kernel.
>>>>
>>>> PF_RING (http://www.ntop.org/PF_RING.html) is a kernel module that
>>>> implements an mmap()-ed memory ring for accelerating packet capture
>>>> and for providing all the basic features a network monitoring
>>>> application needs. PF_RING includes several features such as packet
>>>> filtering, balancing across capture applications, packet reflection
>>>> (i.e. capture application can decide to bounce selected packets  
>>>> onto
>>>> an as-specified interface). Packets are filtered both using BPF and
>>>> using ACL-like rules (e.g. tcp and ports from 80 to 100). Using
>>>> PF_RING it is also possible to exploit multiple RX queues  
>>>> provided by
>>>> modern NIC adapters. PF_RING achieves a significant speedup by  
>>>> making
>>>> only one copy of the packet. Additionally, PF_RING is able to  
>>>> operate
>>>> in a capture-only installation, further increasing performance.
>>>>
>>>> PF_RING has been around since 2003 and is very mature with an  
>>>> active
>>>> contributing developer base. The developer and user community use a
>>>> mailing list (http://listgateway.unipi.it/pipermail/ntop-misc/) for
>>>> discussions and submissions. PF_RING is used in several projects,
>>>> ranging from distributions such as DD-WRT/OpenWrt to improving
>>>> performance of applications like Snort and Wireshark. Many  
>>>> commercial
>>>> companies around the world in the field of intrusion detection and
>>>> traffic analysis rely on PF_RING for accelerating their products  
>>>> and
>>>> operations.
>>>>
>>>> The PF_RING module relies on a small patch to net/core/dev.c that
>>>> intercepts when a packet is received/transmitted so that it can be
>>>> passed to the PF_RING module when present and with an active  
>>>> listener.
>>>> Other than these minor changes, all the PF_RING code is
>>>> self-contained, comprising jut two files: ring.c and ring.h.  
>>>> PF_RING
>>>> is the result of many years of research and development  
>>>> specifically
>>>> into high-speed packet capture, and is homegrown. PF_RING uses the
>>>> stock GPL license.
>>>>
>>>> We feel that PF_RING is ready to be included with the mainline  
>>>> kernel.
>>>> We are ready and eager to support PF_RING for the long term.
>>>>
>>>> Thank you in advance for your consideration!
>>>
>>> I was going to wrap pfring up for the staging tree.
>>> The code you put in network receive path is not necessary;
>>> it would be cleaner to just use existing packet type all hook, and
>>> then PF_RING could be a loadable module without having to be  
>>> compiled in.
>>>
>>> --
>>>
>
> If you want, I'll try and do it. Are there any tests other
> than just ntop?

Re: PF_RING: Include in main line kernel?

[Luca Deri]

David
I agree that some PF_RING features could be merged into PF_PACKET.  
However PF_RING is not just about improving packet capture but it  
implements facilities that can be used by many monitoring applications  
including, packet balancing, reflection, layer-7 packet filtering,  
pf_ring socket clustering just to name a few. You can read about  
PF_RING feature into this tutorial: http://luca.ntop.org/IM2009_Tutorial.pdf

So if the decision is to include in PF_PACKET some unique features  
present in PF_RING, I will not be against that, even if I think that  
the PF_RING design is different from PF_PACKET, that IMHO is limited  
to packet capture.

Regards Luca


On Oct 14, 2009, at 10:15 PM, David Miller wrote:

> From: Luca Deri <deri@ntop.org>
> Date: Wed, 14 Oct 2009 21:54:26 +0200
>
>> - packets to be filtered using both BPF and ACL-like filters
>
> To me this is all that PF_RING adds, the ACL filter features.
>
> And I see no reason why that can't be added to PF_PACKET, we've
> extended PF_PACKET in many ways before (even the mmap ring
> buffer layout can be modified trivially) so there is no reason
> we can't add the ACL filter feature to PF_PACKET as well.
>
> Adding all of PF_RING just for that is a joke.

Re: PF_RING: Include in main line kernel?

[David Miller]

From: Luca Deri <deri@ntop.org>
Date: Wed, 14 Oct 2009 22:17:30 +0200

> Another reason, is that having a hook in dev.c, device drivers can
> pass PF_RING packets directly without going through the standard
> kernel mechanisms. For instance I have developed some drivers that if
> they detect the presence of PF_RING, pass received packets directly to
> PF_RING instead of going with NAPI.

There is absolutely no reason to do this.

If the existing infrastructure isn't good or fast enough,
fix it, don't bypass it.

Re: PF_RING: Include in main line kernel?

[David Miller]

From: Luca Deri <deri@ntop.org>
Date: Wed, 14 Oct 2009 22:26:25 +0200

> I agree that some PF_RING features could be merged into
> PF_PACKET. However PF_RING is not just about improving packet capture
> but it implements facilities that can be used by many monitoring
> applications including, packet balancing, reflection, layer-7 packet
> filtering, pf_ring socket clustering just to name a few. You can read
> about PF_RING feature into this tutorial:
> http://luca.ntop.org/IM2009_Tutorial.pdf

I've already researched several times what PF_RING does and
is capable of doing, and my position still stands that none of
it can't be added to existing facilities.

It's been an out of tree hack for years, and if it stays as
a seperate facility it's likely to stay that way.

Re: PF_RING: Include in main line kernel?

[Luca Deri]

David
so do you want me to start porting PF_RING facilities into PF_PACKET?  
As I have said I;m not against this: my goal is to include this work  
into the linux kernel, as it has been separate for too long.

Luca

On Oct 14, 2009, at 10:29 PM, David Miller wrote:

> From: Luca Deri <deri@ntop.org>
> Date: Wed, 14 Oct 2009 22:26:25 +0200
>
>> I agree that some PF_RING features could be merged into
>> PF_PACKET. However PF_RING is not just about improving packet capture
>> but it implements facilities that can be used by many monitoring
>> applications including, packet balancing, reflection, layer-7 packet
>> filtering, pf_ring socket clustering just to name a few. You can read
>> about PF_RING feature into this tutorial:
>> http://luca.ntop.org/IM2009_Tutorial.pdf
>
> I've already researched several times what PF_RING does and
> is capable of doing, and my position still stands that none of
> it can't be added to existing facilities.
>
> It's been an out of tree hack for years, and if it stays as
> a seperate facility it's likely to stay that way.

Re: PF_RING: Include in main line kernel?

[Evgeniy Polyakov]

On Wed, Oct 14, 2009 at 10:17:30PM +0200, Luca Deri (deri@ntop.org) wrote:
> The reason why I decided to patch dev.c is because I wanted PF_RING to  
> decide whether the packet journey shall continue or not. In other  
> words with my solution PF_RING applications can decide whether the  
> received packets will also be delivered to upper layers (and to other  
> kernel network components). This configurable 'early packet drop'  
> allows the overall performance to be significantly increased as  
> received packets are not supposed to be delivered to upper layers;  
> this is a typical situations for many monitoring devices.

This is a feature many projects implement themself indeed. What about
creating special return value from the packet handler which will
indicate that packet was already consumed and no further work should be
done on it?

-- 
	Evgeniy Polyakov

Re: PF_RING: Include in main line kernel?

[Mark Smith]

Hi Luca, David,

On Wed, 14 Oct 2009 22:34:17 +0200
Luca Deri <deri@ntop.org> wrote:

> David
> so do you want me to start porting PF_RING facilities into PF_PACKET?  
> As I have said I;m not against this: my goal is to include this work  
> into the linux kernel, as it has been separate for too long.
> 

I'd like to see that. One of my main uses for Linux is as a network
troubleshooting "pocket knife", so anything that can improve or make
more functional the packet capturing capabilities is really appreciated
by people like me.

Thanks,
Mark.

> Luca
> 
> On Oct 14, 2009, at 10:29 PM, David Miller wrote:
> 
> > From: Luca Deri <deri@ntop.org>
> > Date: Wed, 14 Oct 2009 22:26:25 +0200
> >
> >> I agree that some PF_RING features could be merged into
> >> PF_PACKET. However PF_RING is not just about improving packet capture
> >> but it implements facilities that can be used by many monitoring
> >> applications including, packet balancing, reflection, layer-7 packet
> >> filtering, pf_ring socket clustering just to name a few. You can read
> >> about PF_RING feature into this tutorial:
> >> http://luca.ntop.org/IM2009_Tutorial.pdf
> >
> > I've already researched several times what PF_RING does and
> > is capable of doing, and my position still stands that none of
> > it can't be added to existing facilities.
> >
> > It's been an out of tree hack for years, and if it stays as
> > a seperate facility it's likely to stay that way.
> 
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: PF_RING: Include in main line kernel?

[Ben Greear]

[-- Attachment #1: Type: text/plain, Size: 1064 bytes --]

On 10/14/2009 01:36 PM, Evgeniy Polyakov wrote:
> On Wed, Oct 14, 2009 at 10:17:30PM +0200, Luca Deri (deri@ntop.org) wrote:
>> The reason why I decided to patch dev.c is because I wanted PF_RING to
>> decide whether the packet journey shall continue or not. In other
>> words with my solution PF_RING applications can decide whether the
>> received packets will also be delivered to upper layers (and to other
>> kernel network components). This configurable 'early packet drop'
>> allows the overall performance to be significantly increased as
>> received packets are not supposed to be delivered to upper layers;
>> this is a typical situations for many monitoring devices.
>
> This is a feature many projects implement themself indeed. What about
> creating special return value from the packet handler which will
> indicate that packet was already consumed and no further work should be
> done on it?

Maybe something similar to the attached patch?

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


[-- Attachment #2: patch0.patch --]
[-- Type: text/plain, Size: 2636 bytes --]

diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 907d118..da78f0a 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -78,6 +78,7 @@ struct wireless_dev;
 #define NET_RX_CN_MOD		3   /* Storm on its way! */
 #define NET_RX_CN_HIGH		4   /* The storm is here */
 #define NET_RX_BAD		5  /* packet dropped due to kernel error */
+#define NET_RX_CONSUMED       6 /* pkt is consumed, stop rx logic here. */
 
 /* NET_XMIT_CN is special. It does not guarantee that this packet is lost. It
  * indicates that the device will soon be dropping packets, or already drops
diff --git a/net/core/dev.c b/net/core/dev.c
index 0101178..d5024b9 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2105,6 +2105,10 @@ static inline struct sk_buff *handle_bridge(struct sk_buff *skb,
 	if (*pt_prev) {
 		*ret = deliver_skb(skb, *pt_prev, orig_dev);
 		*pt_prev = NULL;
+		if (*ret == NET_RX_CONSUMED) {
+			kfree_skb(skb); /* we made a copy in deliver_skb */
+			return NULL;
+		}
 	}
 
 	return br_handle_frame_hook(port, skb);
@@ -2128,6 +2132,10 @@ static inline struct sk_buff *handle_macvlan(struct sk_buff *skb,
 	if (*pt_prev) {
 		*ret = deliver_skb(skb, *pt_prev, orig_dev);
 		*pt_prev = NULL;
+		if (*ret == NET_RX_CONSUMED) {
+			kfree_skb(skb); /* we made a copy in deliver_skb */
+			return NULL;
+		}
 	}
 	return macvlan_handle_frame_hook(skb);
 }
@@ -2185,6 +2193,10 @@ static inline struct sk_buff *handle_ing(struct sk_buff *skb,
 	if (*pt_prev) {
 		*ret = deliver_skb(skb, *pt_prev, orig_dev);
 		*pt_prev = NULL;
+		if (*ret == NET_RX_CONSUMED) {
+			kfree_skb(skb); /* we made a copy in deliver_skb */
+			return NULL;
+		}
 	} else {
 		/* Huh? Why does turning on AF_PACKET affect this? */
 		skb->tc_verd = SET_TC_OK2MUNGE(skb->tc_verd);
@@ -2300,8 +2312,13 @@ int netif_receive_skb(struct sk_buff *skb)
 	list_for_each_entry_rcu(ptype, &ptype_all, list) {
 		if (ptype->dev == null_or_orig || ptype->dev == skb->dev ||
 		    ptype->dev == orig_dev) {
-			if (pt_prev)
+			if (pt_prev) {
 				ret = deliver_skb(skb, pt_prev, orig_dev);
+				if (ret == NET_RX_CONSUMED) {
+					kfree_skb(skb); /* we made a copy in deliver_skb */
+					goto out;
+				}
+			}
 			pt_prev = ptype;
 		}
 	}
@@ -2336,8 +2353,13 @@ ncls:
 		if (ptype->type == type &&
 		    (ptype->dev == null_or_orig || ptype->dev == skb->dev ||
 		     ptype->dev == orig_dev)) {
-			if (pt_prev)
+			if (pt_prev) {
 				ret = deliver_skb(skb, pt_prev, orig_dev);
+				if (ret == NET_RX_CONSUMED) {
+					kfree_skb(skb); /* we made a copy in deliver_skb */
+					goto out;
+				}
+			}
 			pt_prev = ptype;
 		}
 	}

Re: PF_RING: Include in main line kernel?

[Luca Deri]

Ben
the patch implements what I looked for.

Thanks Luca

On Oct 14, 2009, at 11:27 PM, Ben Greear wrote:

> On 10/14/2009 01:36 PM, Evgeniy Polyakov wrote:
>> On Wed, Oct 14, 2009 at 10:17:30PM +0200, Luca Deri (deri@ntop.org)  
>> wrote:
>>> The reason why I decided to patch dev.c is because I wanted  
>>> PF_RING to
>>> decide whether the packet journey shall continue or not. In other
>>> words with my solution PF_RING applications can decide whether the
>>> received packets will also be delivered to upper layers (and to  
>>> other
>>> kernel network components). This configurable 'early packet drop'
>>> allows the overall performance to be significantly increased as
>>> received packets are not supposed to be delivered to upper layers;
>>> this is a typical situations for many monitoring devices.
>>
>> This is a feature many projects implement themself indeed. What about
>> creating special return value from the packet handler which will
>> indicate that packet was already consumed and no further work  
>> should be
>> done on it?
>
> Maybe something similar to the attached patch?
>
> Thanks,
> Ben
>
> -- 
> Ben Greear <greearb@candelatech.com>
> Candela Technologies Inc  http://www.candelatech.com
>
> <patch0.patch>

Re: PF_RING: Include in main line kernel?

[David Miller]

From: Ben Greear <greearb@candelatech.com>
Date: Wed, 14 Oct 2009 14:27:45 -0700

> Maybe something similar to the attached patch?

This is not something I'm interested in applying.

It makes implementing proprietary complete networking stacks
for Linux way too easy.

Instead I'd rather have a GPL exported function that allows indication
of consumption somehow.  That's why we have a special hook for
bonding, so it cannot be abused in proprietary modules.

Re: PF_RING: Include in main line kernel?

[Ben Greear]

On 10/14/2009 02:49 PM, David Miller wrote:
> From: Ben Greear<greearb@candelatech.com>
> Date: Wed, 14 Oct 2009 14:27:45 -0700
>
>> Maybe something similar to the attached patch?
>
> This is not something I'm interested in applying.
>
> It makes implementing proprietary complete networking stacks
> for Linux way too easy.
 >
> Instead I'd rather have a GPL exported function that allows indication
> of consumption somehow.

This would mean one hard-coded hook for every application that wanted
this feature, or is there some way to have a gpl_ptype_all?

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: PF_RING: Include in main line kernel?

[Eric Dumazet]

David Miller a écrit :
> From: Luca Deri <deri@ntop.org>
> Date: Wed, 14 Oct 2009 22:17:30 +0200
> 
>> Another reason, is that having a hook in dev.c, device drivers can
>> pass PF_RING packets directly without going through the standard
>> kernel mechanisms. For instance I have developed some drivers that if
>> they detect the presence of PF_RING, pass received packets directly to
>> PF_RING instead of going with NAPI.
> 
> There is absolutely no reason to do this.
> 
> If the existing infrastructure isn't good or fast enough,
> fix it, don't bypass it.

Indeed. IMHO PF_RING seems a huge pile of hacks to me, that would need
a lot of cleanup work before inclusion.

I had problems with past af_packet mmap implementation on ia32, because
not enough high order pages where available in lowmem.

"tcpdump -s 0" could trigger OOM conditions on loaded machines, not sure
it is still the case after commit 719bfeaae8104fca4ca5d47c02592b08682f14fa
(packet: avoid warnings when high-order page allocation fails)

If mmap() can only use 4K pages, are we still able to capture >4K packets ?

I'll check this.

Re: PF_RING: Include in main line kernel?

[Evgeniy Polyakov]

On Wed, Oct 14, 2009 at 02:49:23PM -0700, David Miller (davem@davemloft.net) wrote:
> > Maybe something similar to the attached patch?
> 
> This is not something I'm interested in applying.
> 
> It makes implementing proprietary complete networking stacks
> for Linux way too easy.

Such kernels will be tainted and thus its bugs and problems will be
clearly indicated by the proprietary module.

> Instead I'd rather have a GPL exported function that allows indication
> of consumption somehow.  That's why we have a special hook for
> bonding, so it cannot be abused in proprietary modules.

I believe bonding with its hook is a historical heritage and priority
absence in packet hooks which do not currently allow something to be
registered very first and steal packets from the stack.

Looks like bonding could be implemented as a packet handler with Ben's
patch applied, isn't it?

-- 
	Evgeniy Polyakov

Re: PF_RING: Include in main line kernel?

[David Miller]

From: Evgeniy Polyakov <zbr@ioremap.net>
Date: Thu, 15 Oct 2009 11:02:34 +0400

> On Wed, Oct 14, 2009 at 02:49:23PM -0700, David Miller (davem@davemloft.net) wrote:
>> Instead I'd rather have a GPL exported function that allows indication
>> of consumption somehow.  That's why we have a special hook for
>> bonding, so it cannot be abused in proprietary modules.
> 
> I believe bonding with its hook is a historical heritage and priority
> absence in packet hooks which do not currently allow something to be
> registered very first and steal packets from the stack.

It is in same category as ingress packet scheduler hook.

Re: PF_RING: Include in main line kernel?

[Rémi Denis-Courmont]

On Wed, 14 Oct 2009 08:33:08 -0600, Brad Doctor <brad.doctor@gmail.com>
wrote:
> On behalf of the users and developers of the PF_RING project, we would
> like to ask consideration to include the PF_RING module in the main
> line kernel.

Maybe this is a stupid comment, but "PF_RING" makes me think we are dealing
with a (new) socket Protocols Family, even though this is not such a
family.

-- 
Rémi Denis-Courmont

Re: PF_RING: Include in main line kernel?

[Ben Greear]

On 10/15/2009 12:02 AM, Evgeniy Polyakov wrote:
> On Wed, Oct 14, 2009 at 02:49:23PM -0700, David Miller (davem@davemloft.net) wrote:
>>> Maybe something similar to the attached patch?
>>
>> This is not something I'm interested in applying.
>>
>> It makes implementing proprietary complete networking stacks
>> for Linux way too easy.
>
> Such kernels will be tainted and thus its bugs and problems will be
> clearly indicated by the proprietary module.
>
>> Instead I'd rather have a GPL exported function that allows indication
>> of consumption somehow.  That's why we have a special hook for
>> bonding, so it cannot be abused in proprietary modules.
>
> I believe bonding with its hook is a historical heritage and priority
> absence in packet hooks which do not currently allow something to be
> registered very first and steal packets from the stack.
>
> Looks like bonding could be implemented as a packet handler with Ben's
> patch applied, isn't it?

Bonding, bridging, mac-vlans, pktgen-rx logic, sniffers, and others could.  The only trick is
ordering...it may be better to keep the hard-coded hooks in a definite
order than to allow users to switch them around.

Or, could have a precedence value when adding hooks (protocols) so that modules
can properly order themselves by default, but users *could* reorder
them if they really wanted to (might be useful to have mac-vlans before
bonding some of the time, and after it others, for instance...)

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: PF_RING: Include in main line kernel?

[Harald Welte]

Hi Brad and Luca,

On Wed, Oct 14, 2009 at 08:33:08AM -0600, Brad Doctor wrote:
 
> On behalf of the users and developers of the PF_RING project, we would
> like to ask consideration to include the PF_RING module in the main
> line kernel.

First of all, let me state that I think the mainline support for nProbe/nTop is
something that I have been hoping for many years.  I think the performance you
are achieving is remarkable, and it would be very usable to have this
capability of high performance zero-copy packet access from userspace as a
stock feature of the Linux kernel.

The actual PF_RING implementation has been criticized a couple of times even in
the past.  One general point I remember from past discussions in the kernel
network community was that there is too much overlap with PF_PACKET, and that
this could possibly be extended with a ring buffer rather than replaced with a
fairly similar alternative mechanism.

So let's see what kind of solution the current discussion thread will come up
with... let's hope eventually we'll have the functionality in the kernel.
-- 
- Harald Welte <laforge@gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)

Re: PF_RING: Include in main line kernel?

[Harald Welte]

Hi Dave,

On Wed, Oct 14, 2009 at 02:49:23PM -0700, David Miller wrote:

> > Maybe something similar to the attached patch?
> 
> This is not something I'm interested in applying.
> 
> It makes implementing proprietary complete networking stacks
> for Linux way too easy.

How does it make it any easier?  Even right now you can implement an entire
protocol family in your own module, either by registering as netpoll handler,
or even using the regular dev_add_pack().

-- 
- Harald Welte <laforge@gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)

Re: PF_RING: Include in main line kernel?

[Harald Welte]

Hi Ben,

On Thu, Oct 15, 2009 at 09:33:53AM -0700, Ben Greear wrote:

> Bonding, bridging, mac-vlans, pktgen-rx logic, sniffers, and others could.
> The only trick is ordering...it may be better to keep the hard-coded hooks in
> a definite order than to allow users to switch them around.

why does this sound like the netfilter hooks with their priorities to me?  The
only difference is that netfilter hooks are inside the layer 3 protocols at the
moment, whereas this is one layer lower...

-- 
- Harald Welte <laforge@gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)

[OT] ntop / GPL (was Re: PF_RING: Include in main line kernel?)

[Harald Welte]

Hi Jarek, Brad, Luca,

[putting my gpl-violations.org hat on]

On Wed, Oct 14, 2009 at 06:46:11PM +0200, Jarek Poplawski wrote:
> Brad Doctor wrote, On 10/14/2009 04:33 PM:
> 
> > Download ntop
> > 
> > ntop is distributed under the GNU GPL. In order to be entitled to download
> > ntop you must accept the GNU license. 
> 
> I can't find such a thing neither in GNU GPL v2:

This is true.  The GPL does never need to be accepted for mere use (i.e.
running) the program.  This is at least true for the continental european
copyright systems, where any legally obtained copy of a program implicitly
carries the permission for running the program.  Only for any other activity
you will need to accept the license.

but, like others posted in this thread, ntop is not the PF_RING code.

-- 
- Harald Welte <laforge@gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)

Re: PF_RING: Include in main line kernel?

[Harald Welte]

On Wed, Oct 14, 2009 at 09:54:26PM +0200, Luca Deri wrote:
> Brent
> contrary to other socket types, PF_RING allows
> - packets to be filtered using both BPF and ACL-like filters
> - parsing information is returned as metadata with the packet (i.e.
> you don't have to parse the packet again as it happens with BPF)
> - ACL-like filters allows you to specify advanced features such as
> port ranges or packet payload match

So it seems there is some added features over the existing functionality, plus
probably increased performance mainly to hooking earlier in the packet receive
flow.

What would normally be done is to try to make incremental changes
to the existing code and extend their features/performacne, rather than
adding something relatively similar alternative.

> I agree with you that PF_RING has some overlaps with PACKET_RX/
> TX_RING, but the main idea behind PF_RING is not just to accelerate
> packet capture. For instance in PF_RING you can have actions
> attached to rules, or extend PF_RING filtering/packet handling by
> means of plugins.

Is this in the actual kernel code?  I am not sure whether people generally want
to see ayet another packet filter in Linux ;)

Regards,
-- 
- Harald Welte <laforge@gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)

Re: PF_RING: Include in main line kernel?

[Harald Welte]

Dear Luca,

On Wed, Oct 14, 2009 at 10:34:17PM +0200, Luca Deri wrote:

> so do you want me to start porting PF_RING facilities into
> PF_PACKET? As I have said I;m not against this: my goal is to
> include this work into the linux kernel, as it has been separate for
> too long.

I would suggest you do some analysis of each of the features that PF_RING
currently offers, and think about how each those features could be added
as an incremental change to PF_PACKET.

Then post this as a RFC to the list, see what people think about each of those
issues and follow with the actual implementation.  If you think the actual
implementation might be easier than to make a written proposal, that would
of course also be great.

Regards,
-- 
- Harald Welte <laforge@gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)

Re: PF_RING: Include in main line kernel?

[Evgeniy Polyakov]

On Sun, Oct 18, 2009 at 02:43:37PM +0200, Harald Welte (laforge@gnumonks.org) wrote:
> How does it make it any easier?  Even right now you can implement an entire
> protocol family in your own module, either by registering as netpoll handler,
> or even using the regular dev_add_pack().

Well, it does, since packet will be processed by the main stack after
that, and module will work with the copy only. But I agree that this is
a weak argument.

If it is still a blocking one, what about implementing additional
gpl-only list of handlers which will have 'consumed' skb check? I
believe it would be enough to put it only in single place after the
bridge?

-- 
	Evgeniy Polyakov

Re: PF_RING: Include in main line kernel?

[Evgeniy Polyakov]

On Sun, Oct 18, 2009 at 02:50:14PM +0200, Harald Welte (laforge@gnumonks.org) wrote:
> > contrary to other socket types, PF_RING allows
> > - packets to be filtered using both BPF and ACL-like filters
> > - parsing information is returned as metadata with the packet (i.e.
> > you don't have to parse the packet again as it happens with BPF)
> > - ACL-like filters allows you to specify advanced features such as
> > port ranges or packet payload match
> 
> So it seems there is some added features over the existing functionality, plus
> probably increased performance mainly to hooking earlier in the packet receive
> flow.
> 
> What would normally be done is to try to make incremental changes
> to the existing code and extend their features/performacne, rather than
> adding something relatively similar alternative.

PF_PACKET as is can not be made faster - it requires a packet copy, so
virtually this is an end of the game, while mapped packet socket is
quite different and does not require that expensive copy. And while
currently difference between both goes down, it still exists and may
hummer some use cases.

PF_RING uses another ring structure and I saw comparisons of both (many
years ago though), where pf_ring was faster. Unfortunately there is no
way to easily adopt its mapping into pf_packet ring without breaking
compatibility, but I wonder whether performance different between both
still exists and can it be a main factor for the preference. If
difference is not visible, than I believe the only way for PF_RING is to
extend existing packet sockets with its other features.

-- 
	Evgeniy Polyakov

Re: PF_RING: Include in main line kernel?

[Luca Deri]

Harald
many thanks for your support. As I have stated before my wish is to  
include into the the mainstream kernel some features that I have  
implemented in PF_RING and on which many users rely since very long  
time. I understand that there are some overlaps with PF_PACKET and I'm  
willing to work with the kernel maintainers to address this issue.

The only thing I want to say is that PF_RING is *not* just for  
accelerating packet capture. This was the minimal goal when in 2003 I  
have coded the first release. PF_RING is a kernel module that  
implements several features (e.g. advanced packet filtering,  
extensible architecture by means of plugins, balancing, multicore/ 
multiqueue, packet modification and retransmission) that ease the  
implementation of efficient applications not limited to packet capture  
application. So in this view PF_RING has been designed to be a  
superset of PF_PACKET, because the needs I (and many other people  
have) are not of just having efficient packet capture.

This said I'm already at work to modify PF_RING so that it's a pure  
module that does not require any change in the mainstream kernel (i.e.  
net/core/dev.c). I'm almost done so I plan to release by tomorrow a  
new PF_RING release that implements this. Of course some changes into  
the kernel (such as Ben's patch) would ease PF_RING's life and pave  
the way to new kernel modules.

Done that I will start working at the RFC that you proposed.

Cheers Luca

PS. Just to clarify, when I say 'packet filtering' I mean the ability  
for packet capture applications to specify filters more advanced that  
BPF (even if BPF is supported by PF_RING) that prevent those  
applications from receiving packets they don't like, but that in any  
case will continue their journey into the kernel; this has nothing to  
do with netfilter filtering).

On Oct 18, 2009, at 2:38 PM, Harald Welte wrote:

> Hi Brad and Luca,
>
> On Wed, Oct 14, 2009 at 08:33:08AM -0600, Brad Doctor wrote:
>
>> On behalf of the users and developers of the PF_RING project, we  
>> would
>> like to ask consideration to include the PF_RING module in the main
>> line kernel.
>
> First of all, let me state that I think the mainline support for  
> nProbe/nTop is
> something that I have been hoping for many years.  I think the  
> performance you
> are achieving is remarkable, and it would be very usable to have this
> capability of high performance zero-copy packet access from  
> userspace as a
> stock feature of the Linux kernel.
>
> The actual PF_RING implementation has been criticized a couple of  
> times even in
> the past.  One general point I remember from past discussions in the  
> kernel
> network community was that there is too much overlap with PF_PACKET,  
> and that
> this could possibly be extended with a ring buffer rather than  
> replaced with a
> fairly similar alternative mechanism.
>
> So let's see what kind of solution the current discussion thread  
> will come up
> with... let's hope eventually we'll have the functionality in the  
> kernel.
> -- 
> - Harald Welte <laforge@gnumonks.org>           http://laforge.gnumonks.org/
> = 
> = 
> = 
> = 
> = 
> = 
> ======================================================================
> "Privacy in residential applications is a desirable marketing option."
>                                                  (ETSI EN 300 175-7  
> Ch. A6)

Re: [OT] ntop / GPL (was Re: PF_RING: Include in main line kernel?)

[Jarek Poplawski]

On Sun, Oct 18, 2009 at 02:47:06PM +0200, Harald Welte wrote:
> Hi Jarek, Brad, Luca,
> 
> [putting my gpl-violations.org hat on]
> 
> On Wed, Oct 14, 2009 at 06:46:11PM +0200, Jarek Poplawski wrote:
> > Brad Doctor wrote, On 10/14/2009 04:33 PM:
> > 
> > > Download ntop
> > > 
> > > ntop is distributed under the GNU GPL. In order to be entitled to download
> > > ntop you must accept the GNU license. 
> > 
> > I can't find such a thing neither in GNU GPL v2:
> 
> This is true.  The GPL does never need to be accepted for mere use (i.e.
> running) the program.  This is at least true for the continental european
> copyright systems, where any legally obtained copy of a program implicitly
> carries the permission for running the program.  Only for any other activity
> you will need to accept the license.
> 
> but, like others posted in this thread, ntop is not the PF_RING code.

ntop doesn't matter here at all:

if ((X uses the stock GPL license.) &&
    (Y is distributed under the GNU GPL) &&
    (In order to be entitled to download Y
     you must accept the GNU license.) &&
    (The GPL does never need to be accepted for mere use.))

	is logically false.

BTW, legal systems don't matter here at all.

Jarek P.

Re: [OT] ntop / GPL (was Re: PF_RING: Include in main line kernel?)

[Jarek Poplawski]

On Mon, Oct 19, 2009 at 05:55:21AM +0000, Jarek Poplawski wrote:
> On Sun, Oct 18, 2009 at 02:47:06PM +0200, Harald Welte wrote:
> > Hi Jarek, Brad, Luca,
> > 
> > [putting my gpl-violations.org hat on]
> > 
> > On Wed, Oct 14, 2009 at 06:46:11PM +0200, Jarek Poplawski wrote:
> > > Brad Doctor wrote, On 10/14/2009 04:33 PM:
> > > 
> > > > Download ntop
> > > > 
> > > > ntop is distributed under the GNU GPL. In order to be entitled to download
> > > > ntop you must accept the GNU license. 
> > > 
> > > I can't find such a thing neither in GNU GPL v2:
> > 
> > This is true.  The GPL does never need to be accepted for mere use (i.e.
> > running) the program.  This is at least true for the continental european
> > copyright systems, where any legally obtained copy of a program implicitly
> > carries the permission for running the program.  Only for any other activity
> > you will need to accept the license.
> > 
> > but, like others posted in this thread, ntop is not the PF_RING code.
> 
> ntop doesn't matter here at all:

Or more precisely: "ntop is not PF_RING code" doesn't matter here,
because it all suggests we have a false statement wrt. PF_RING.
(But Brad acknowledged this needs the change.)

> 
> if ((X uses the stock GPL license.) &&
>     (Y is distributed under the GNU GPL) &&
>     (In order to be entitled to download Y
>      you must accept the GNU license.) &&
>     (The GPL does never need to be accepted for mere use.))
> 
> 	is logically false.
> 
> BTW, legal systems don't matter here at all.

IOW: if this point of GNU GPL isn't true for some copyright system,
means GNU GPL can't be valid in such a system.

Jarek P.