[ovs-dev] [PATCHv2] lib: upgrade to DPDK 1.8

Ben Pfaff blp at nicira.com
Mon Feb 9 16:16:56 UTC 2015


It's not the ofpbufs that are leaked.  Where is 's' freed?  Before your
patch, the data in 's' was put into an ofpbuf, and eventually freed.
After your patch, the data in 's' is always copied a second time, by
ofpbuf_clone_data(), and then the copy is put into an ofpbuf (and
eventually freed), but 's' itself appears to be leaked.

On Mon, Feb 09, 2015 at 04:12:58PM +0000, Kavanagh, Mark B wrote:
> Hi Ben,
> 
> I don't think so - jsonrpc_run() empties the rpc output queue, freeing the ofpbufs, after their contents are sent to the stream.
> 
> Thanks,
> Mark
> 
> > -----Original Message-----
> > From: Ben Pfaff [mailto:blp at nicira.com]
> > Sent: Friday, February 6, 2015 8:41 PM
> > To: Kavanagh, Mark B
> > Cc: dev at openvswitch.org; Rory Sexton
> > Subject: Re: [ovs-dev] [PATCHv2] lib: upgrade to DPDK 1.8
> > 
> > On Fri, Feb 06, 2015 at 04:43:26PM +0000, Mark Kavanagh wrote:
> > > DPDK v1.8.0 makes significant changes to struct rte_mbuf, including
> > > removal of the 'pkt' and 'data' fields. The latter, formally a
> > > pointer, is now calculated via an offset from the start of the
> > > segment buffer. These fields are referenced by OVS when accessing
> > > the data section of an ofpbuf.
> > >
> > > The following changes are required to add support for DPDK 1.8:
> > > - update affected functions to use the correct rte_mbuf fields
> > > - remove init function from netdev-dpdk (no longer required as
> > >   rte_eal_pci_probe is now invoked from eal_init)
> > > - split large amounts of data across multiple ofpbufs; with the
> > >   removal of the mbuf's 'data' pointer, and replacement with a
> > >   'data_off' field, it is necessary to limit the size of data
> > >   contained in an ofpbuf to UINT16_MAX when mbufs are used
> > >   (data_off and data_len are both of type uint16_t).
> > >   Were data not split across multiple ofpbufs, values larger
> > >   than UINT16_MAX for 'data_len' and 'data_off' would result
> > >   in wrap-around, and consequently, data corruption. Changes
> > >   introduced in this patch prevent this from occurring.
> > >
> > > Signed-off-by: Mark Kavanagh <mark.b.kavanagh at intel.com>
> > > Signed-off-by: Mark Gray <mark.d.gray at intel.com>
> > > Signed-off-by: Rory Sexton <rory.sexton at intel.com>
> > 
> > At first glance, at least, this patch introduces a memory leak into
> > jsonrpc_send().
> > 
> > Thanks,
> > 
> > Ben.



More information about the dev mailing list