From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Burakov, Anatoly" Subject: Re: [PATCH v2 08/16] Add support for mapping devices through VFIO. Date: Thu, 22 May 2014 12:37:50 +0000 Message-ID: References: <6426409.afQ7rpamsg@xps13> <1871082.JnAAVjVYKa@xps13> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: "dev-VfR2kkLFssw@public.gmane.org" To: Thomas Monjalon Return-path: In-Reply-To: <1871082.JnAAVjVYKa@xps13> Content-Language: en-US List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces-VfR2kkLFssw@public.gmane.org Sender: "dev" Hi Thomas, > Yes, in some environments, it could be easier to be able to configure dev= ices > directly on application command line instead of having to call a python s= cript. > I think having a clear and extendable syntax to configure devices in comm= and > line could greatly improve usability. But it can be another step. That's probably out of scope for this patch. We can discuss this later with= out stalling VFIO :) > What do you think of _mp_sync or _mp_conf? > Usage of the socket is to synchronize VFIO config between processes, righ= t? More or less, yes. However, the code inside that file is the communication = mechanism. I.e. it's not actually synchronizing or configuring anything, it= 's simply providing means to do so for primary and secondary processes, so = I don't think _mp_sync or _mp_conf is a good name for that. IMO something l= ike _mp_socket or similar (_mp_comm?) would be more appropriate.=20 > Oh yes. Do you think you could merge the thread spawning in the patch > adding it? Good point, I'll do that. > So you should use an "extern" trick in order to have only one instance of= the > variables. But I think it's not a good practice. > You probably need to group functions using these variables in one .c file= . > Or do I miss something? I'll look into this. Best regards, Anatoly Burakov DPDK SW Engineer