On Sun, Jan 15, 2017 at 06:14:47PM +0000, Stokes, Ian wrote:
> > Since it's possible to delete memory pool in DPDK we can try to estimate
> > better required memory size when port is reconfigured, e.g. with different
> > number of rx queues.
>
> Thanks for the patch.
>
> It will need to be rebased for it to apply cleanly to master.
Yes, this patch waits here for quite some time. I need to rebase it and send
once again.
> I've applied the changes manually just to test and from what I can see there
> are no issues.
> It also resolves issue reported with having 64 queues for dpdk physical ports
> which causes ovs to crash.
Thanks for testing
>
> A few other comments below.
> >
> > Signed-off-by: Robert Wojciechowicz <robertx.wojciechow...@intel.com>
> > ---
> > lib/netdev-dpdk.c | 85 +++++++++++++++++++++++++++-----------------------
> > -----
> > 1 file changed, 41 insertions(+), 44 deletions(-)
> >
> > diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c index 7c1523e..4c9e1e8
> > 100644
> > --- a/lib/netdev-dpdk.c
> > +++ b/lib/netdev-dpdk.c
[...]
> >
> > static struct dpdk_mp *
> > -dpdk_mp_get(int socket_id, int mtu)
> > +dpdk_mp_get(struct netdev_dpdk *dev, int mtu)
> > {
> > struct dpdk_mp *dmp;
> >
> > ovs_mutex_lock(&dpdk_mp_mutex);
> > - LIST_FOR_EACH (dmp, list_node, &dpdk_mp_list) {
> > - if (dmp->socket_id == socket_id && dmp->mtu == mtu) {
> > - dmp->refcount++;
> > - goto out;
> > - }
> > - }
> > -
> As you remove the use of dpdk_mp_list above, I wonder is there a need to
> maintain the global list?
> With mempools now set on a per netdev basis, perhaps the global list could be
> removed also. Thoughts?
>
I was thinking about that when I prepared this patch. In this implementation
memory pool
will be always used only by one port, so I could get rid of `refcount` and
`dpdk_mp_list`.
I didn't do that because I didn't want to make huge revolution in the
implementation
without even knowing if this idea of separated memory pools makes sense for the
community.
Now I have positive feedbak from you, so maybe it's worth it to work on this
patch further.
Br,
Robert
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
