DPDK patches and discussions
 help / color / mirror / Atom feed
* [dpdk-dev] mbuf->packet_type
@ 2020-11-02 10:45 Levend Sayar
  2020-11-03  7:32 ` Levend Sayar
  0 siblings, 1 reply; 3+ messages in thread
From: Levend Sayar @ 2020-11-02 10:45 UTC (permalink / raw)
  To: dev

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [dpdk-dev] mbuf->packet_type
  2020-11-02 10:45 [dpdk-dev] mbuf->packet_type Levend Sayar
@ 2020-11-03  7:32 ` Levend Sayar
  2020-11-03  8:02   ` Juhamatti Kuusisaari
  0 siblings, 1 reply; 3+ messages in thread
From: Levend Sayar @ 2020-11-03  7:32 UTC (permalink / raw)
  To: dev

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 <levendsayar@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
>

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [dpdk-dev] mbuf->packet_type
  2020-11-03  7:32 ` Levend Sayar
@ 2020-11-03  8:02   ` Juhamatti Kuusisaari
  0 siblings, 0 replies; 3+ messages in thread
From: Juhamatti Kuusisaari @ 2020-11-03  8:02 UTC (permalink / raw)
  To: Levend Sayar; +Cc: dev

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 <levendsayar@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 <levendsayar@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
> >

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2020-11-03  8:02 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-11-02 10:45 [dpdk-dev] mbuf->packet_type Levend Sayar
2020-11-03  7:32 ` Levend Sayar
2020-11-03  8:02   ` Juhamatti Kuusisaari

DPDK patches and discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://inbox.dpdk.org/dev/0 dev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 dev dev/ https://inbox.dpdk.org/dev \
		dev@dpdk.org
	public-inbox-index dev

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.dpdk.org/inbox.dpdk.dev


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git