> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Ananyev,
> Konstantin
> > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Olivier Matz
> > On Fri, Jan 11, 2019 at 10:56:11AM +0300, Andrew Rybchenko wrote:
> > > On 1/11/19 3:11 AM, Stephen Hemminger wrote:
> > > > On Thu, 10 Jan 2019 03:
uh
> Subject: Re: [dpdk-dev] [RFC] function to parse packet headers
>
> Hi,
>
> On Fri, Jan 11, 2019 at 10:56:11AM +0300, Andrew Rybchenko wrote:
> > On 1/11/19 3:11 AM, Stephen Hemminger wrote:
> > > On Thu, 10 Jan 2019 03:03:24 +0200
> > > Rami Rosen w
Hi,
On Fri, Jan 11, 2019 at 10:56:11AM +0300, Andrew Rybchenko wrote:
> On 1/11/19 3:11 AM, Stephen Hemminger wrote:
> > On Thu, 10 Jan 2019 03:03:24 +0200
> > Rami Rosen wrote:
> >
> > > Hi, Morten,
> > >
> > > > And regarding avoiding code duplicity, I'm pursuing Olivier about
> > > > mergin
On 1/11/19 11:16 AM, Morten Brørup wrote:
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Andrew Rybchenko
On 1/11/19 3:11 AM, Stephen Hemminger wrote:
All drivers that don't have hardware support for getting l2/l3 and
ptype information should be calling rte_net_get_ptype() already.
Is it
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Andrew Rybchenko
> On 1/11/19 3:11 AM, Stephen Hemminger wrote:
> >
> > All drivers that don't have hardware support for getting l2/l3 and
> > ptype information should be calling rte_net_get_ptype() already.
>
> Is it documented somewhere?
>
On 1/11/19 3:11 AM, Stephen Hemminger wrote:
On Thu, 10 Jan 2019 03:03:24 +0200
Rami Rosen wrote:
Hi, Morten,
And regarding avoiding code duplicity, I'm pursuing Olivier about merging
packet header validation into rte_net_get_ptype() instead of writing a
separate function.
This seems al
On Thu, 10 Jan 2019 03:03:24 +0200
Rami Rosen wrote:
> Hi, Morten,
>
> > And regarding avoiding code duplicity, I'm pursuing Olivier about merging
> packet header validation into rte_net_get_ptype() instead of writing a
> separate function.
> >
> This seems also a good alternative.
> +1
>
>
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of
> long...@viettel.com.vn
>
> Also for the bulk API, another option would be passing in a `uint64_t
> malformed_mask` and let the bulk function set the correspond bit (1 <<
> pos) of that mask if the packet at position pos is malformed.
>
> vo
el.com.vn; roszenr...@gmail.com; Olivier Matz
>
> Cc: dev@dpdk.org
> Subject: RE: [dpdk-dev] [RFC] function to parse packet headers
>
> Cutting in Olivier, requesting input as the maintainer of rte_net.
>
> > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of
> > long..
Hi, Morten,
> And regarding avoiding code duplicity, I'm pursuing Olivier about merging
packet header validation into rte_net_get_ptype() instead of writing a
separate function.
>
This seems also a good alternative.
+1
Regards,
Rami Rosen
>
>
>
Adding few more Cc's
09/01/2019 16:53, Morten Brørup:
> From: Rami Rosen [mailto:roszenr...@gmail.com]
> >Hi Morten,
> >A good idea, thanks for volunteering!
> >Several minor comments:
> >I would consider calling it rte_mbuf_hdr_parse(), to make it more related to
> >the rte_mbuf* methods, and
From: Rami Rosen [mailto:roszenr...@gmail.com]
>Hi Morten,
>A good idea, thanks for volunteering!
>Several minor comments:
>I would consider calling it rte_mbuf_hdr_parse(), to make it more related to
>the rte_mbuf* methods, and also I would consider having it in librte_mbuf and
>not in librte
Cutting in Olivier, requesting input as the maintainer of rte_net.
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of
> long...@viettel.com.vn
>
> Hi Morten,
>
> What is the difference compare to rte_net_get_ptype(), which also
> parses
> packet types and reports on header length.
>
> In my
Hi Morten,
What is the difference compare to rte_net_get_ptype(), which also parses
packet types and reports on header length.
In my application I have also done something similar about malformed
packets. IMO it's very useful to have return value indicate different types
of malformed packets, not
Hi Morten,
A good idea, thanks for volunteering!
Several minor comments:
I would consider calling it rte_mbuf_hdr_parse(), to make it more related
to the rte_mbuf* methods, and also I would consider having it in
librte_mbuf and not in librte_net as you suggested.
Also regarding the bulk method. Th
I'm volunteering to provide a function to set the mbuf's l2_len/l3_len/...
(tx_offload) fields by parsing the packet headers, possibly assisted by the
packet_type field, if set.
I'm seeking initial feedback before submitting my first version of the code.
The single packet parser function header
16 matches
Mail list logo
