On Fri, Mar 13, 2020 at 11:30 PM Coyle, David wrote:
>
> >
> > On Fri, Mar 6, 2020 at 8:25 PM Coyle, David wrote:
> > >
> > > > >
> > > > > /** Error Detection Algorithms */
> > > > > enum rte_rawdev_multi_fn_err_detect_algorithm {
> > > > > RTE_RAWDEV_MULTI_FN_ERR_DETECT_CRC32_ETH,
> > >
>
> On Fri, Mar 6, 2020 at 8:25 PM Coyle, David wrote:
> >
> > > >
> > > > /** Error Detection Algorithms */
> > > > enum rte_rawdev_multi_fn_err_detect_algorithm {
> > > > RTE_RAWDEV_MULTI_FN_ERR_DETECT_CRC32_ETH,
> > >
> > > IMO, It does not make sense to add protocol specific stuff in
On Fri, Mar 6, 2020 at 8:25 PM Coyle, David wrote:
>
> > >
> > > /** Error Detection Algorithms */
> > > enum rte_rawdev_multi_fn_err_detect_algorithm {
> > > RTE_RAWDEV_MULTI_FN_ERR_DETECT_CRC32_ETH,
> >
> > IMO, It does not make sense to add protocol specific stuff in rawdev
> > symbols.
> >
> > /** Error Detection Algorithms */
> > enum rte_rawdev_multi_fn_err_detect_algorithm {
> > RTE_RAWDEV_MULTI_FN_ERR_DETECT_CRC32_ETH,
>
> IMO, It does not make sense to add protocol specific stuff in rawdev
> symbols.
>
> IMO, It is better to have a separate library for CRC and BIP3
On Thu, Mar 5, 2020 at 10:14 PM Coyle, David wrote:
>
> Having taken feedback from the community into account, we would like to
> propose some changes to our approach for combining multiple packet-processing
> functions into a single operation on a single device, be that an optimized
> software
On Thu, Mar 5, 2020 at 10:32 PM Coyle, David wrote:
>
> > >
> > > Having an API that could be used by parallel hardware does make sense,
> > > but the DPDK already has multiple packet processing infrastructure pieces.
> > >
> > > I would rather the DPDK converge on one widely used, robust and test
> >
> > Having an API that could be used by parallel hardware does make sense,
> > but the DPDK already has multiple packet processing infrastructure pieces.
> >
> > I would rather the DPDK converge on one widely used, robust and tested
> > packet method. Rather than the current "choose your poison
Having taken feedback from the community into account, we would like to propose
some changes to our approach for combining multiple packet-processing functions
into a single operation on a single device, be that an optimized software
library or a hardware accelerator.
The main feedback on the r
On Thu, Feb 13, 2020 at 5:14 PM Doherty, Declan
wrote:
>
> On 06/02/2020 5:13 PM, Jerin Jacob wrote:
> > On Thu, Feb 6, 2020 at 10:01 PM Coyle, David wrote:
> >
> > Hi David,
> >
> >>>
> >>>
> >> - XGS-PON MAC: Crypto-CRC-BIP
> >> - Order:
> >> - Downstream:
On Thu, Feb 13, 2020 at 5:20 PM Doherty, Declan
wrote:
>
> On 07/02/2020 2:18 PM, Jerin Jacob wrote:
> > On Fri, Feb 7, 2020 at 6:08 PM Coyle, David wrote:
> >>
> >> Hi Jerin, see below
> >
> > Hi David,
> >
> >>>
> >>> On Thu, Feb 6, 2020 at 10:01 PM Coyle, David
> >>> wrote:
> >>>
> >
> >>>
>
On Thu, Feb 13, 2020 at 5:01 PM Doherty, Declan
wrote:
>
> On 06/02/2020 10:54 AM, Jerin Jacob wrote:
> > On Thu, Feb 6, 2020 at 3:35 PM Coyle, David wrote:
> >>
> >> Hi Jerin,
> >
> > Hi David,
> >
> >> Thanks for the comments. Please see replies below.
> >>
> >> Kind Regards,
> >> David
> >>
>
On 07/02/2020 2:18 PM, Jerin Jacob wrote:
On Fri, Feb 7, 2020 at 6:08 PM Coyle, David wrote:
Hi Jerin, see below
Hi David,
On Thu, Feb 6, 2020 at 10:01 PM Coyle, David
wrote:
There is a risk in drafting API that meant for HW without any HW exists.
Because there could be inefficiency
On 06/02/2020 5:13 PM, Jerin Jacob wrote:
On Thu, Feb 6, 2020 at 10:01 PM Coyle, David wrote:
Hi David,
- XGS-PON MAC: Crypto-CRC-BIP
- Order:
- Downstream: CRC, Encrypt, BIP
I understand if the chain has two operations then it may possible to
have handcrafted S
On 06/02/2020 10:54 AM, Jerin Jacob wrote:
On Thu, Feb 6, 2020 at 3:35 PM Coyle, David wrote:
Hi Jerin,
Hi David,
Thanks for the comments. Please see replies below.
Kind Regards,
David
On Tue, Feb 4, 2020 at 8:15 PM David Coyle wrote:
Introduction
This RFC introduces a
On Sat, Feb 8, 2020 at 2:04 AM Stephen Hemminger
wrote:
>
> On Fri, 7 Feb 2020 19:48:17 +0530
> Jerin Jacob wrote:
>
> > On Fri, Feb 7, 2020 at 6:08 PM Coyle, David wrote:
> > >
> > > Hi Jerin, see below
> >
> > Hi David,
> >
> > > >
> > > > On Thu, Feb 6, 2020 at 10:01 PM Coyle, David
> > > >
On Fri, 7 Feb 2020 19:48:17 +0530
Jerin Jacob wrote:
> On Fri, Feb 7, 2020 at 6:08 PM Coyle, David wrote:
> >
> > Hi Jerin, see below
>
> Hi David,
>
> > >
> > > On Thu, Feb 6, 2020 at 10:01 PM Coyle, David
> > > wrote:
> > >
>
> > >
> > > There is a risk in drafting API that meant for H
On Fri, Feb 7, 2020 at 6:08 PM Coyle, David wrote:
>
> Hi Jerin, see below
Hi David,
> >
> > On Thu, Feb 6, 2020 at 10:01 PM Coyle, David
> > wrote:
> >
> >
> > There is a risk in drafting API that meant for HW without any HW exists.
> > Because there could be inefficiency on the metadata and
Hi Jerin, see below
>
> On Thu, Feb 6, 2020 at 10:01 PM Coyle, David
> wrote:
>
> Hi David,
>
> > >
> > >
> > > > > > - XGS-PON MAC: Crypto-CRC-BIP
> > > > > > - Order:
> > > > > > - Downstream: CRC, Encrypt, BIP
> > > > >
> > > > > I understand if the chain has two ope
On Thu, Feb 6, 2020 at 10:01 PM Coyle, David wrote:
Hi David,
> >
> >
> > > > > - XGS-PON MAC: Crypto-CRC-BIP
> > > > > - Order:
> > > > > - Downstream: CRC, Encrypt, BIP
> > > >
> > > > I understand if the chain has two operations then it may possible to
> > > > have han
Hi Jerin, see reply below
> On Thu, Feb 6, 2020 at 3:35 PM Coyle, David wrote:
> >
> > Hi Jerin,
>
> Hi David,
>
> > Thanks for the comments. Please see replies below.
> >
> > Kind Regards,
> > David
> >
> > > On Tue, Feb 4, 2020 at 8:15 PM David Coyle
> wrote:
> > > >
> > > > Introduction
> >
On Thu, Feb 6, 2020 at 3:35 PM Coyle, David wrote:
>
> Hi Jerin,
Hi David,
> Thanks for the comments. Please see replies below.
>
> Kind Regards,
> David
>
> > On Tue, Feb 4, 2020 at 8:15 PM David Coyle wrote:
> > >
> > > Introduction
> > >
> > >
> > > This RFC introduces a new DPD
Hi Jerin,
Thanks for the comments. Please see replies below.
Kind Regards,
David
> On Tue, Feb 4, 2020 at 8:15 PM David Coyle wrote:
> >
> > Introduction
> >
> >
> > This RFC introduces a new DPDK library, rte_accelerator.
> >
> > The main aim of this library is to provide a flexibl
On Tue, Feb 4, 2020 at 8:15 PM David Coyle wrote:
>
> Introduction
>
>
> This RFC introduces a new DPDK library, rte_accelerator.
>
> The main aim of this library is to provide a flexible and extensible way of
> combining one or more packet-processing functions into a single operatio
Introduction
This RFC introduces a new DPDK library, rte_accelerator.
The main aim of this library is to provide a flexible and extensible way of
combining one or more packet-processing functions into a single operation,
thereby allowing these to be performed in parallel in optimiz
24 matches
Mail list logo
