[Intel-wired-lan] [PATCH iwl-next v9 00/15] Introduce the Parser Library

[Tom Herbert]

On Thu, Sep 7, 2023 at 12:10 PM Samudrala, Sridhar
<sridhar.samudrala at intel.com> wrote:
>
>
>
> On 9/5/2023 6:05 PM, Tom Herbert wrote:
> <snip>
>
> > Yes, creating an elaborate mechanism that is only usable for one
> > vendor, e.g. a feature of DDP, really isn't very helpful. Parsing is a
> > very common operation in the networking stack, and if there's
> > something with the vanglorious name of "Parser Library" really should
> > start off as being a common, foundational, vendor agnostic library to
> > solve the larger problem and provide the most utility. The common
> > components would define consistent user and kernel interfaces for
> > parser offload, interfaces into the NIC drivers would be defined to
> > allow different vendors to implement parser offload in their devices.
>
> I think naming this framework as 'parser library' may have caused the
> misunderstanding. Will fix in the next revision. This is not a generic
> network packet parser and not applicable to kernel flow dissector. It is
> specific to ice and enables the driver to learn the hardware parser
> capabilities from the DDP package that is downloaded to hardware. This
> information along with the raw packet/mask is used to figure out all the
> metadata required to add a filter rule.

Sriidhar,

Okay, the DDP includes a programmable parser to some extent, and these
patches support the driver logic to support that programmable hardware
parser in ICE. It's still unclear to me how the rest of the world will
use this. When you say you the information "is used to figure out all
the metadata required to add a filter rule", who is adding these
filter rules and what APIs are they using? Considering you mention
it's not applicable to kernel flow dissector that leads me to believe
that you're viewing hardware parser capabilities to be independent of
the kernel and might even be using vendor proprietary tools to program
the parser. But as I said, hardware parsers are becoming common, users
benefit if we can provide common and consistent tools to program and
use them.

For instance, the draft mentions the Flow Director use case. How does
the user program the device for a new protocol in Flow Director? Do
you expect this to be done using common APIs, or would you use some
common API like TC Flower offload. And note that while Flow Director
might be Intel specific and not visible to the kernel, something like
aRFS is visible to the kernel but could benefit from a programmable
hardware parser as well. And really, when you think about, what we
really want for RSS, Flow DIrector, and aRFS is *exactly* an offload
the kernel flow director because those are effectively offloads of RPS
and RFS which rely on flow dissector for packet steering in the host
(in fact, the very first flow dissector was created exactly to produce
as packet hash for use with RPS).

Wrt flow dissector, the missing piece is that it's not user
programmable, every time we add a new protocol it's a major pain and
there's no way for users to add their own custom protocols. Frankly,
it's also spaghetti code that is prone to bugs (I take liberty in
calling it spaghetti code because I am one of the parties responsible
for creating it :-) ). We are working to completely replace the flow
dissector with an eBPF program to solve that. I don't believe we
should force devices to run an eBPF VM, so in order to do parser
offload we can start with a higher layer abstraction of the parser in
a declarative representation (for instance, see the Common Parser
Language I presented at netdev conference). Given the abstracted
program, the idea is that a compiler could produce the instructions to
program the hardware parser in a device with the exact same
functionality that we'd have in a programmable kernel flow dissector.
In this way, we can achieve a proper parser offload.

So I think one of the requirements in hardware parsers is to offload
flow dissector. If that is the requirement, do you think these patches
are aligned with that?

Tom