I keep getting a bounce on rory.sex...@intel.com ("550 #5.1.0 Address
rejected."). Is that email address correct?On Mon, Feb 9, 2015 at 8:16 AM, Ben Pfaff <b...@nicira.com> wrote: > 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:b...@nicira.com] >> > Sent: Friday, February 6, 2015 8:41 PM >> > To: Kavanagh, Mark B >> > Cc: dev@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.kavan...@intel.com> >> > > Signed-off-by: Mark Gray <mark.d.g...@intel.com> >> > > Signed-off-by: Rory Sexton <rory.sex...@intel.com> >> > >> > At first glance, at least, this patch introduces a memory leak into >> > jsonrpc_send(). >> > >> > Thanks, >> > >> > Ben. -- "I don't normally do acked-by's. I think it's my way of avoiding getting blamed when it all blows up." Andrew Morton _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
