All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Rogers, Gerald" <gerald.rogers-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
To: "Venkatesan,
	Venky" <venky.venkatesan-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
	Olivier MATZ
	<olivier.matz-pdR9zngts4EAvxtiuMwx3w@public.gmane.org>,
	Igor Ryzhov <iryzhov-p3dJzl6UAic@public.gmane.org>,
	"dev-VfR2kkLFssw@public.gmane.org"
	<dev-VfR2kkLFssw@public.gmane.org>
Subject: Re: RTE Ring removing
Date: Wed, 7 May 2014 15:36:23 +0000	[thread overview]
Message-ID: <CF8FA000.5364B%gerald.rogers@intel.com> (raw)
In-Reply-To: <1FD9B82B8BF2CF418D9A1000154491D9740A339F-P5GAC/sN6hlcIJlls4ac1rfspsVTdybXVpNB7YpNyf8@public.gmane.org>

Venky,

This also applies to mbuf pools.  Inside of the openvswitch.org patches we
allocate mbuf pools for a port, but we are unable to free them back when
the port is removed.

One other request (maybe it is there, and I¹m unaware), is the ability to
dynamically add / remove a physical port to DPDK.  Basically we should be
able to reassign on the fly a port from the kernel to DPDK, and vice versa
(of course with the caveat that all structures be released in both
environments and a port reinitialized).

Gerald

On 5/7/14, 7:01 AM, "Venkatesan, Venky" <venky.venkatesan-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote:

>Olivier, 
>
>We should look at how to make the memseg capable of doing alloc/free
>(including re-assembly of fragments) after the 1.7 release. Is that
>something you are considering doing (or are there any other DPDKers
>considering this), or should I look at putting together a patch for that?
>
>Regards, 
>-Venky
>
>-----Original Message-----
>From: dev [mailto:dev-bounces-VfR2kkLFssw@public.gmane.org] On Behalf Of Olivier MATZ
>Sent: Wednesday, May 07, 2014 4:39 AM
>To: Igor Ryzhov; dev-VfR2kkLFssw@public.gmane.org
>Subject: Re: [dpdk-dev] RTE Ring removing
>
>Hi Igor,
>
>On 05/07/2014 09:54 AM, Igor Ryzhov wrote:
>> I noticed that in Memzone realization there is a special global
>> variable "free_memseg" containing pointers on free memory segments.
>> An memzone reserve function just finst the best segment for allocation
>> from this "free_memseg" variable.
>>
>> So I think there is a possibility to unreserve already reserved memory
>> back to "free_memseg", and impossibility of unreserving memory is just
>> because there is no function for that, not because it is impossible in
>> principle.
>> Am I right? Or there are any restrictions?
>
>I think that implementing a freeing of memory segment is feasible, but it
>would require some work to properly merge freed zones to avoid memory
>fragmentation.
>
>Another solution is to allocate/free rings in standard memory (malloc for
>instance) instead of rte_memzones. Let me know if the patches I've just
>sent on the mailing list solves your issue.
>
>By the way, I plan to do the same thing for mempools in the coming weeks
>but there is much more work.
>
>Regards,
>Olivier
>

      parent reply	other threads:[~2014-05-07 15:36 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-06  9:05 RTE Ring removing Igor Ryzhov
     [not found] ` <5368A5E0.8090903-p3dJzl6UAic@public.gmane.org>
2014-05-07  7:54   ` Igor Ryzhov
     [not found]     ` <5369E6AF.4040402-p3dJzl6UAic@public.gmane.org>
2014-05-07 11:39       ` Olivier MATZ
     [not found]         ` <536A1B5C.2010201-pdR9zngts4EAvxtiuMwx3w@public.gmane.org>
2014-05-07 12:42           ` Igor Ryzhov
     [not found]             ` <536A2A44.1030801-p3dJzl6UAic@public.gmane.org>
2014-05-07 13:08               ` Olivier MATZ
2014-05-07 14:01           ` Venkatesan, Venky
     [not found]             ` <1FD9B82B8BF2CF418D9A1000154491D9740A339F-P5GAC/sN6hlcIJlls4ac1rfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2014-05-07 15:09               ` Olivier MATZ
     [not found]                 ` <536A4CB3.9000005-pdR9zngts4EAvxtiuMwx3w@public.gmane.org>
2014-05-07 15:19                   ` Ananyev, Konstantin
     [not found]                     ` <2601191342CEEE43887BDE71AB9772580EFA401D-kPTMFJFq+rEu0RiL9chJVbfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2014-05-07 15:37                       ` Olivier MATZ
2014-05-07 15:36               ` Rogers, Gerald [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CF8FA000.5364B%gerald.rogers@intel.com \
    --to=gerald.rogers-ral2jqcrhueavxtiumwx3w@public.gmane.org \
    --cc=dev-VfR2kkLFssw@public.gmane.org \
    --cc=iryzhov-p3dJzl6UAic@public.gmane.org \
    --cc=olivier.matz-pdR9zngts4EAvxtiuMwx3w@public.gmane.org \
    --cc=venky.venkatesan-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.