Hello Levend,
The packet type is indeed filled by hw in case there is a support for
it. I think your application may be missing a ptype handling function
which checks the supported ptype handling of the hw and registers a
callback handling in case the hw does not support it.
Please see more details e.g. in l3fwd example application about the
ptype checks and callback registration.
Best regards,
--
Juhamatti
On Tue, 3 Nov 2020 at 09:33, Levend Sayar <levendsa...@gmail.com> wrote:
>
> Hi all.
>
> Nobody cared about my mail. Am I in the wrong place?
> If so, can you forward me to the right place please?
>
> Best,
> Levend
>
> On Mon, Nov 2, 2020 at 1:45 PM Levend Sayar <levendsa...@gmail.com> wrote:
>
> > Hi all.
> >
> > Recently I encountered a dont-know-why issue about mbuf->packet_type.
> >
> > Two different setups behave differently.
> >
> > One is a bare metal server, one KVM based OpenStack VM (virtio).
> > Both use the uio driver. Namely only hardware is different. Software stack
> > is the same.
> >
> > But this macro does not work on OpenStack platform.
> >
> > *RTE_ETH_IS_IPV4_HDR(mbuf->packet_type))*
> >
> > where
> >
> > *#define RTE_ETH_IS_IPV4_HDR(ptype) ((ptype) & RTE_PTYPE_L3_IPV4)*
> >
> > I manually coded to check IPv4 like this:
> >
> >
> >
> >
> > *struct rte_ether_hdr* ether_hdr = rte_pktmbuf_mtod(mbuf, struct
> > rte_ether_hdr*);uint16_t ether_type = N2H16(ether_hdr->ether_type);if
> > (likely(ether_type == RTE_ETHER_TYPE_IPV4)) {*
> >
> > Do you have any idea about this?
> > I suppose whoever fills that mbuf data packet_type field is not working in
> > a virtual environment.
> > Which entity fills that fields? Hardware driver, uio, dpdk?
> >
> > Best,
> > Levend
> >
