DPDK patches and discussions
 help / color / mirror / Atom feed
* [dpdk-dev] ovs-dpdk: ofpbuf reinitialization
@ 2015-03-25 19:25 Zoltan Kiss
  2015-03-25 19:45 ` [dpdk-dev] [ovs-dev] " Pravin Shelar
  0 siblings, 1 reply; 2+ messages in thread
From: Zoltan Kiss @ 2015-03-25 19:25 UTC (permalink / raw)
  To: dev, dev

Hi,

Looking around in the DPDK code I've found that it only initializes the 
packet metadata (whih contains the struct ofpbuf belonging to the 
packet) during setup, as the packet initializer of rte_mempool_create.
That means that every time a packet buffer is released back by OVS to 
the buffer pool, it retains ofpbuf state, and it doesn't change when the 
poll mode driver use the buffer again to store a new packet. "source" 
and "allocated members of ofpbuf shouldn't change, but frame, 
l2_pad_size and the offsets does at various places. Even though I 
couldn't establish an error scenario yet, I think it's quite dangerous 
to leave the packet to inherit the previous packet's ofpbuf.
Or am I missing some place where this piece is reinitialized?

Regards,

Zoltan Kiss

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

* Re: [dpdk-dev] [ovs-dev] ovs-dpdk: ofpbuf reinitialization
  2015-03-25 19:25 [dpdk-dev] ovs-dpdk: ofpbuf reinitialization Zoltan Kiss
@ 2015-03-25 19:45 ` Pravin Shelar
  0 siblings, 0 replies; 2+ messages in thread
From: Pravin Shelar @ 2015-03-25 19:45 UTC (permalink / raw)
  To: Zoltan Kiss; +Cc: dev, dev

On Wed, Mar 25, 2015 at 12:25 PM, Zoltan Kiss <zoltan.kiss@linaro.org> wrote:
> Hi,
>
> Looking around in the DPDK code I've found that it only initializes the
> packet metadata (whih contains the struct ofpbuf belonging to the packet)
> during setup, as the packet initializer of rte_mempool_create.
> That means that every time a packet buffer is released back by OVS to the
> buffer pool, it retains ofpbuf state, and it doesn't change when the poll
> mode driver use the buffer again to store a new packet. "source" and
> "allocated members of ofpbuf shouldn't change, but frame, l2_pad_size and
> the offsets does at various places. Even though I couldn't establish an
> error scenario yet, I think it's quite dangerous to leave the packet to
> inherit the previous packet's ofpbuf.
> Or am I missing some place where this piece is reinitialized?
>

l2_pad and offsets are initialized during flow extraction. These
fields should not be accessed before this step.

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

end of thread, other threads:[~2015-03-25 19:46 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-03-25 19:25 [dpdk-dev] ovs-dpdk: ofpbuf reinitialization Zoltan Kiss
2015-03-25 19:45 ` [dpdk-dev] [ovs-dev] " Pravin Shelar

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