Moving this discussion to the ODP mailing list.

Allowing ODP-based applications running on a SmartNIC is an excellent
way to accomplish two goals:

1. Allow non-ODP apps as well as the host OS itself to access SmartNIC
services via a standardized mechanism.

2. Allow advanced ODP apps to divide themselves between a host portion
and a SmartNIC portion that can do preprocessing on data as it is
coming off the wire before it is made visible to the host.

While most of the discussion sessions we will be having at BUD17 will
be focused on items we want to deliver as part of the ODP Tiger Moth
release, it's good to be a bit more forward looking to see what's
beyond that both to gauge interest as well as to understand new
opportunities for growth. Having a single portable API that spans from
host down onto the SmartNIC can only further broaden ODP's industry
appeal.

On Fri, Feb 10, 2017 at 10:22 AM, Francois Ozog
<[email protected]> wrote:
> Good point.
>
> Please introduce it with your comments ;-)
>
> On 10 February 2017 at 16:54, Bill Fischofer <[email protected]> 
> wrote:
>> Does this need to be on LNG-Internal? This sounds like a good
>> discussion to be having on the main ODP mailing list. Can we move this
>> important discussion there?
>>
>> On Fri, Feb 10, 2017 at 9:50 AM, Francois Ozog <[email protected]> 
>> wrote:
>>> Hello,
>>>
>>> I would like to open a discussion on ODP over PCI.
>>>
>>> During the NFV BoF that happened in LAS16 I briefly touched on a way
>>> to expose SmartNICs in a PCI environment:
>>> - an ODP instance runs on the SmartNIC
>>> - a software on the host (another ODP instance or something else) is
>>> using a PCI device to convey ODP API calls which are effectively
>>> "executed" on the SmartNIC.
>>>
>>> This is essentially an ODP split model based on a RPC over PCI through
>>> the device. When we will have Layer1, Layer2, Layer3
>>> switching/forwarding ODP functional blocks (complementing classifier,
>>> scheduler...) this could become very interesting.
>>>
>>> Some benefits of this:
>>> - expose ODP value indirectly through the kernel (I mean Linux just
>>> sees a SmartNIC)
>>> - facilitate introduction of network related acceleration in the Linux 
>>> kernel
>>> - need of SINGLE device driver for all ODP SmartNICs.
>>> - it can be applied to baremetal, containers and VM
>>>
>>>
>>> Implementation ideas:
>>> - translate API calls into a protocol
>>> - bind the protocol to the PCI bus
>>> - create a server side thread on ODP to handle the requests
>>> - create frontends
>>>     . for the ODP in the host
>>>     . for the kernel
>>>
>>> For the kernel, can the kernel driver be implemented as an eBPF program ? 
>>> ;-)
>>> Should we integrat switchdev ?
>>>
>>> Now, your turn to comment,challenge....
>>>
>>> FF
>
>
>
> --
> François-Frédéric Ozog | Director Linaro Networking Group
> T: +33.67221.6485
> [email protected] | Skype: ffozog

Reply via email to