From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 52BFA957A for ; Wed, 6 Jan 2016 06:56:43 +0100 (CET) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga102.jf.intel.com with ESMTP; 05 Jan 2016 21:56:43 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,528,1444719600"; d="scan'208";a="875441268" Received: from shwdeisgchi083.ccr.corp.intel.com (HELO [10.239.67.119]) ([10.239.67.119]) by fmsmga001.fm.intel.com with ESMTP; 05 Jan 2016 21:56:41 -0800 To: dev@dpdk.org References: <1447930650-26023-2-git-send-email-mukawa@igel.co.jp> <1450255049-2263-1-git-send-email-mukawa@igel.co.jp> <1450255049-2263-3-git-send-email-mukawa@igel.co.jp> <004a01d14166$f52be7e0$df83b7a0$@samsung.com> <568C9093.9020706@igel.co.jp> From: "Tan, Jianfeng" Message-ID: <568CAC99.1040305@intel.com> Date: Wed, 6 Jan 2016 13:56:41 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <568C9093.9020706@igel.co.jp> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v1 2/2] virtio: Extend virtio-net PMD to support container environment X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 05:56:43 -0000 On 1/6/2016 11:57 AM, Tetsuya Mukawa wrote: > On 2015/12/28 20:57, Pavel Fedin wrote: >> Hello! >> >>> diff --git a/drivers/net/virtio/virtio_pci.h b/drivers/net/virtio/virtio_pci.h >>> index 47f722a..d4ede73 100644 >>> --- a/drivers/net/virtio/virtio_pci.h >>> +++ b/drivers/net/virtio/virtio_pci.h >>> @@ -165,6 +165,9 @@ struct virtqueue; >>> >>> struct virtio_hw { >>> struct virtqueue *cvq; >>> +#ifdef RTE_LIBRTE_VIRTIO_HOST_MODE >>> + void *qsession; >>> +#endif >>> uint32_t io_base; >>> uint32_t guest_features; >>> uint32_t max_tx_queues; >>> @@ -226,6 +229,26 @@ outl_p(unsigned int data, unsigned int port) >>> } >>> #endif >>> >>> +#ifdef RTE_LIBRTE_VIRTIO_HOST_MODE >>> + >>> +uint32_t virtio_ioport_read(struct virtio_hw *, uint64_t, char type); >>> +void virtio_ioport_write(struct virtio_hw *, uint64_t, uint64_t, char type); >>> + >>> +#define VIRTIO_READ_REG_1(hw, reg) \ >>> + virtio_ioport_read(hw, reg, 'b') >>> +#define VIRTIO_WRITE_REG_1(hw, reg, value) \ >>> + virtio_ioport_write(hw, reg, value, 'b') >>> +#define VIRTIO_READ_REG_2(hw, reg) \ >>> + virtio_ioport_read(hw, reg, 'w') >>> +#define VIRTIO_WRITE_REG_2(hw, reg, value) \ >>> + virtio_ioport_write(hw, reg, value, 'w') >>> +#define VIRTIO_READ_REG_4(hw, reg) \ >>> + virtio_ioport_read(hw, reg, 'l') >>> +#define VIRTIO_WRITE_REG_4(hw, reg, value) \ >>> + virtio_ioport_write(hw, reg, value, 'l') >>> + >>> +#else /* RTE_LIBRTE_VIRTIO_HOST_MODE */ >>> + >> I have a concern against such compile-time switches. What if we want the same code to work for both 'real' virtio and socket-based? >> Shouldn't we introduce some function pointers here to be able to switch them at runtime? > Hi Pavel, > > Thanks for commenting. > In that case, you will run QEMU, then create containers in the guest. > Do you have an use case for this usage? > > Anyway, such a feature depends on how to allocate share memory. > So far, this patch allow you to run both virtio-net 'real' and 'virtual' > PMDs on guest, but it will be changed to remove contiguous memory > restriction. > Could you please see an other thread that we talk about the restriction > in? (I will add you to CC.) > > Thanks, > Tetsuya Hi Tetsuya, I prefer to a compiled library to work well in both VM and container. For this issue, we can address this issue using Yuanhan's way to address virtio 1.0 support. (He introduces struct virtio_pci_ops) Thanks, Jianfeng