On 6/1/2016 2:53 PM, Yuanhan Liu wrote:
> On Wed, Jun 01, 2016 at 06:40:41AM +0000, Xie, Huawei wrote:
>>> /* Retrieve all of the head indexes first to avoid caching issues. */
>>> for (i = 0; i < count; i++) {
>>> - desc_indexes[i] = vq-&g
On 5/3/2016 8:42 AM, Yuanhan Liu wrote:
> Both current kernel virtio driver and DPDK virtio driver use at least
> 2 desc buffer for Tx: the first for storing the header, and the others
> for storing the data.
>
> Therefore, we could fetch the first data desc buf before the main loop,
> and do the
On 6/1/2016 2:41 PM, Yuanhan Liu wrote:
> On Wed, Jun 01, 2016 at 06:24:18AM +0000, Xie, Huawei wrote:
>> On 5/3/2016 8:42 AM, Yuanhan Liu wrote:
>>> Both current kernel virtio driver and DPDK virtio driver use at least
>>> 2 desc buffer for Tx: the first for storing
On 6/2/2016 4:52 PM, Yuanhan Liu wrote:
> On Thu, Jun 02, 2016 at 08:39:36AM +0000, Xie, Huawei wrote:
>> On 6/1/2016 2:03 PM, Yuanhan Liu wrote:
>>> On Wed, Jun 01, 2016 at 05:40:08AM +, Xie, Huawei wrote:
>>>> On 5/30/2016 4:20 PM, Yuanhan Liu wrote:
>>&g
On 6/1/2016 2:03 PM, Yuanhan Liu wrote:
> On Wed, Jun 01, 2016 at 05:40:08AM +0000, Xie, Huawei wrote:
>> On 5/30/2016 4:20 PM, Yuanhan Liu wrote:
>>> On Wed, May 25, 2016 at 12:16:41AM +0800, Huawei Xie wrote:
>>>> There is no external function call or any barrier i
On 6/2/2016 4:07 PM, Xie, Huawei wrote:
> We keep a common vq structure, containing only vq related fields,
> and then split others into RX, TX and control queue respectively.
>
> Signed-off-by: Huawei Xie
sorry, this is v4.
On 6/1/2016 3:13 PM, Yuanhan Liu wrote:
> On Mon, May 30, 2016 at 05:06:20PM +0800, Huawei Xie wrote:
>> We keep a common vq structure, containing only vq related fields,
>> and then split others into RX, TX and control queue respectively.
>>
>> Signed-off-by: Huawei Xie
>> ---
>> v2:
>> - don't
On 5/3/2016 8:42 AM, Yuanhan Liu wrote:
> the ifname[] field takes so much space, that it seperate some frequently
> used fields into different caches, say, features and broadcast_rarp.
>
> This patch move all those fields that will be accessed frequently in Rx/Tx
> together (before the ifname[]
On 5/3/2016 8:42 AM, Yuanhan Liu wrote:
> Pre update and update used ring in batch for Tx and Rx at the stage
> while fetching all avail desc idx. This would reduce some cache misses
> and hence, increase the performance a bit.
>
> Pre update would be feasible as guest driver will not start
On 5/3/2016 8:42 AM, Yuanhan Liu wrote:
> Both current kernel virtio driver and DPDK virtio driver use at least
> 2 desc buffer for Tx: the first for storing the header, and the others
> for storing the data.
Tx could prepend some space for virtio net header whenever possible, so
that it could
On 5/27/2016 10:08 AM, Yuanhan Liu wrote:
> On Wed, May 25, 2016 at 12:47:30PM +0200, Thomas Monjalon wrote:
>>> - dev->devargs->type != RTE_DEVTYPE_WHITELISTED_PCI) {
>>> + (!dev->devargs ||
>>> +dev->devargs->type != RTE_DEVTYPE_WHITELISTED_PCI)) {
>>
On 5/30/2016 4:20 PM, Yuanhan Liu wrote:
> On Wed, May 25, 2016 at 12:16:41AM +0800, Huawei Xie wrote:
>> There is no external function call or any barrier in the loop,
>> the used->idx would only be retrieved once.
>>
>> Signed-off-by: Huawei Xie
>> ---
>> drivers/net/virtio/virtio_ethdev.c | 3
On 5/30/2016 11:00 AM, Yuanhan Liu wrote:
> On Mon, May 30, 2016 at 02:40:00AM +0000, Xie, Huawei wrote:
>> On 5/27/2016 5:06 PM, Yuanhan Liu wrote:
>>> On Tue, May 24, 2016 at 09:38:32PM +0800, Huawei Xie wrote:
>>>>vq->vq_ring_mem = mz->phys_addr;
>
On 5/27/2016 5:06 PM, Yuanhan Liu wrote:
> On Tue, May 24, 2016 at 09:38:32PM +0800, Huawei Xie wrote:
>> vq->vq_ring_mem = mz->phys_addr;
>> vq->vq_ring_virt_mem = mz->addr;
>> -PMD_INIT_LOG(DEBUG, "vq->vq_ring_mem: 0x%"PRIx64,
>> (uint64_t)mz->phys_addr);
>> -
On 5/25/2016 2:06 PM, Christian Ehrhardt wrote:
> Hi,
> ping ...
>
> Later on I want to look at it again once we upgraded to more recent
> releases of the software components involved, but those have to be made
> ready to use first :-/
>
> But the description is good and I wonder if anybody else
ed, May 25, 2016 at 08:25:20AM +, Xie, Huawei wrote:
>>>>> On 5/25/2016 4:12 PM, Xie, Huawei wrote:
>>>>>> There is no external function call or any barrier in the loop,
>>>>>> the used->idx would only be retrieved once.
>>>&g
On 5/25/2016 4:12 PM, Xie, Huawei wrote:
> There is no external function call or any barrier in the loop,
> the used->idx would only be retrieved once.
>
> Signed-off-by: Huawei Xie
> ---
> drivers/net/virtio/virtio_ethdev.c | 3 ++-
> 1 file changed, 2 insertions(+)
On 5/10/2016 4:42 PM, Michael S. Tsirkin wrote:
> On Tue, May 10, 2016 at 08:07:00AM +0000, Xie, Huawei wrote:
>> On 5/10/2016 3:56 PM, Michael S. Tsirkin wrote:
>>> On Tue, May 10, 2016 at 07:24:10AM +, Xie, Huawei wrote:
>>>> On 5/10/2016 2:08 AM, Yuanhan L
tely, making it non-work any more, unless a driver reset
> is done.
s/DPDK app/DPDK vhost/
DPDK app is confusing
>
> So, instead of getting the stale vring base from QEMU, Huawei suggested
> we could get a proper one from used->idx.
>
> Cc: "Michael S. Tsirkin"
On 5/10/2016 3:56 PM, Michael S. Tsirkin wrote:
> On Tue, May 10, 2016 at 07:24:10AM +0000, Xie, Huawei wrote:
>> On 5/10/2016 2:08 AM, Yuanhan Liu wrote:
>>> On Mon, May 09, 2016 at 04:47:02PM +, Xie, Huawei wrote:
>>>> On 5/7/2016 2:36 PM, Yuanhan
On 5/10/2016 2:08 AM, Yuanhan Liu wrote:
> On Mon, May 09, 2016 at 04:47:02PM +0000, Xie, Huawei wrote:
>> On 5/7/2016 2:36 PM, Yuanhan Liu wrote:
>>> +static void *
>>> +vhost_user_client_reconnect(void *arg)
>>> +{
>>> + struct
On 5/7/2016 2:36 PM, Yuanhan Liu wrote:
> +static void *
> +vhost_user_client_reconnect(void *arg)
> +{
> + struct reconnect_info *reconn = arg;
> + int ret;
> +
> + RTE_LOG(ERR, VHOST_CONFIG, "reconnecting...\n");
> + while (1) {
> + ret = connect(reconn->fd, (struct
On 5/7/2016 2:36 PM, Yuanhan Liu wrote:
> However, Michael claims some concerns: he made a good point: a crash
> is happening means some memory is corrupted, and it could be the virtio
> memory being corrupted. In such case, nothing will work without the
> reset.
I don't get this point. What is
On 5/9/2016 6:45 PM, Victor Kaplansky wrote:
>> diff --git a/lib/librte_vhost/virtio-net.c b/lib/librte_vhost/virtio-net.c
>> > index c88aaa3..df103aa 100644
>> > --- a/lib/librte_vhost/virtio-net.c
>> > +++ b/lib/librte_vhost/virtio-net.c
>> > @@ -560,6 +560,14 @@ vhost_set_vring_addr(int vid,
> -Original Message-
> From: Yuanhan Liu [mailto:yuanhan.liu at linux.intel.com]
> Sent: Monday, May 09, 2016 1:15 PM
> To: Xie, Huawei
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] virtio: split virtio rx/tx queue
>
> On Thu, May 05, 2016 at 05:29
On 5/5/2016 12:21 AM, Vincent Li wrote:
> Hi,
>
> I am running the dpdk git repo which already had commit ac5e1d838dc
> (virtio: skip error when probing kernel managed device), but in my
> test, it seems still taking control of the kernel managed virtio
> device and segmentation fault, here is the
On 5/5/2016 11:46 AM, Yuanhan Liu wrote:
> On Thu, May 05, 2016 at 03:29:44AM +0000, Xie, Huawei wrote:
>> On 5/5/2016 11:03 AM, Yuanhan Liu wrote:
>>> On Thu, May 05, 2016 at 01:54:25AM +, Xie, Huawei wrote:
>>>> On 5/5/2016 7:59 AM, Yuanhan Liu wrote:
>>&g
On 5/5/2016 11:03 AM, Yuanhan Liu wrote:
> On Thu, May 05, 2016 at 01:54:25AM +0000, Xie, Huawei wrote:
>> On 5/5/2016 7:59 AM, Yuanhan Liu wrote:
>>> On Wed, May 04, 2016 at 08:50:27AM +0800, Huawei Xie wrote:
>>>> -int virtio_dev_queue_setup(struct rte_eth_dev *de
On 5/5/2016 7:59 AM, Yuanhan Liu wrote:
> On Wed, May 04, 2016 at 08:50:27AM +0800, Huawei Xie wrote:
>> -int virtio_dev_queue_setup(struct rte_eth_dev *dev,
>> -int queue_type,
>> -uint16_t queue_idx,
>> +static int
>> +virtio_dev_cq_queue_setup(struct
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Vincent Li
> Sent: Thursday, May 05, 2016 12:21 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] virtio still blindly take over virtio device managed
> by kernel
>
> Hi,
>
> I am running the dpdk git repo
On 4/20/2016 10:19 PM, Bruce Richardson wrote:
> On Tue, Mar 22, 2016 at 10:55:26AM +0100, Jan Blunck wrote:
>> v3 changes:
>> - removed fake PCI interface
>> - removed struct virt_eth_driver
>> - check for UIO name and version
>> - added basic documentation
>>
>> Jan Blunck (3):
>> xen: Add UIO
On 4/28/2016 4:14 PM, Thomas Monjalon wrote:
> 2016-04-27 23:19, Yuanhan Liu:
>> And applied to dpdk-next-virtio, with few tiny changes:
>>
>> - we normally put suggested/reported-by above the SoB.
> Yes we must keep the chronological order in these lines.
>
Thanks for reminder
On 4/24/2016 9:24 PM, Xie, Huawei wrote:
> On 4/24/2016 5:15 PM, Michael S. Tsirkin wrote:
>> On Sun, Apr 24, 2016 at 02:45:22AM +0000, Xie, Huawei wrote:
>>> Forget to cc the mailing list.
>>>
>>> On 4/22/2016 9:53 PM, Xie, Huawei wrote:
>>>> Hi
On 4/25/2016 10:37 AM, Tan, Jianfeng wrote:
> Issue: when using virtio nic to transmit pkts, it causes segment fault.
>
> How to reproduce:
> Basically, we need to construct a case with vm send packets to vhost-user,
> and this issue does not happen when transmitting packets using indirect
> desc.
On 4/24/2016 5:15 PM, Michael S. Tsirkin wrote:
> On Sun, Apr 24, 2016 at 02:45:22AM +0000, Xie, Huawei wrote:
>> Forget to cc the mailing list.
>>
>> On 4/22/2016 9:53 PM, Xie, Huawei wrote:
>>> Hi:
>>>
>>> This is a series of virtio/vhost idx/
On 4/22/2016 6:43 AM, Yuanhan Liu wrote:
> On Thu, Apr 21, 2016 at 12:36:10PM +, Jianfeng Tan wrote:
>> Issue: when using virtio nic to transmit pkts, it causes segment fault.
> Jianfeng,
>
> It's good to describe the issues, steps to reproduce it and how to fix
> it. But you don't have to
On 4/10/2016 7:26 AM, chintu hetam wrote:
> I am compiling DPDK 2.2 on Fedora 23 and i am seeing following build error
> /home/vcr/devel/dpdk/dpdk-2.2.0/build/build/lib/librte_eal/linuxapp/kni/kni_vhost.c:
> In function ?kni_sock_poll?:
>
On 4/11/2016 1:29 AM, Zhe Tao wrote:
>
> +/* Check the share memory in case the QEMU doesn't set the share option
> + * as on for the memory-backend-file object in the QEMU command line.
> + */
> +
> +int
> +vhost_check_mem_shared(struct vhost_device_ctx ctx)
> +{
> + struct virtio_net *dev;
On 4/7/2016 10:52 PM, Christian Ehrhardt wrote:
> I totally agree to that there is no deterministic rule what to expect.
> The only rule is that #fd certainly always is > #vhost_user devices.
> In various setup variants I've crossed fd 1024 anywhere between 475
> and 970 vhost_user ports.
>
> Once
On 4/7/2016 3:52 PM, Thomas Monjalon wrote:
> 2016-04-07 06:20, Xie, Huawei:
>> Hi Stephen:
>> I recall that you ever send a netfront PMD patch. I think that is one
>> missing piece for running PMD in XEN domU. There are still users
>> requiring that feature. Could you
Hi Stephen:
I recall that you ever send a netfront PMD patch. I think that is one
missing piece for running PMD in XEN domU. There are still users
requiring that feature. Could you resend that patch? I could help review.
On 3/18/2016 5:15 PM, Patrik Andersson wrote:
> Protect against DPDK crash when allocation of listen fd >= 1023.
> For events on fd:s >1023, the current implementation will trigger
> an abort due to access outside of allocated bit mask.
>
> Corrections would include:
>
> * Match fdset_add()
On 3/18/2016 8:24 PM, Ilya Maximets wrote:
> Since commit 4c02e453cc62 ("eal: introduce SMP memory barriers") virtio
> uses architecture dependent SMP barriers. vHost should use them too.
>
> Fixes: 4c02e453cc62 ("eal: introduce SMP memory barriers")
>
> Signed-off-by: Ilya Maximets
Acked-by:
On 3/22/2016 6:13 PM, Richardson, Bruce wrote:
> On Mon, Mar 21, 2016 at 05:47:44PM +0000, Xie, Huawei wrote:
>> On 3/18/2016 10:17 PM, Bruce Richardson wrote:
>>> On Fri, Mar 18, 2016 at 01:47:29PM +0100, Mauricio V?squez wrote:
>>>> Hi,
>>>>
>>
On 3/18/2016 10:17 PM, Bruce Richardson wrote:
> On Fri, Mar 18, 2016 at 01:47:29PM +0100, Mauricio V?squez wrote:
>> Hi,
>>
>>
>> On Fri, Mar 18, 2016 at 11:35 AM, Thomas Monjalon > 6wind.com
>>> wrote:
>>> 2016-03-18 11:27, Olivier Matz:
On 03/18/2016 11:18 AM, Bruce Richardson wrote:
On 3/21/2016 10:07 PM, Ananyev, Konstantin wrote:
>
>> -Original Message-
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Ilya Maximets
>> Sent: Monday, March 21, 2016 4:50 AM
>> To: Yuanhan Liu
>> Cc: dev at dpdk.org; Xie, Huawei; Dyasly Sergey
On 3/18/2016 6:39 PM, Ilya Maximets wrote:
>
> On 18.03.2016 13:27, Xie, Huawei wrote:
>> On 3/18/2016 6:23 PM, Ilya Maximets wrote:
>>> On 18.03.2016 13:08, Xie, Huawei wrote:
>>>> On 2/24/2016 7:47 PM, Ilya Maximets wrote:
>>>>>
On 3/18/2016 6:23 PM, Ilya Maximets wrote:
> On 18.03.2016 13:08, Xie, Huawei wrote:
>> On 2/24/2016 7:47 PM, Ilya Maximets wrote:
>>> * Wait until it's our turn to add our buffer
>>> @@ -979,7 +979,7 @@ rte_vhost_dequeue_burst(struct virtio_net *
On 3/18/2016 5:55 PM, Ilya Maximets wrote:
> Hi all.
> And what about first patch of this series:
> "vhost: use SMP barriers instead of compiler ones." ?
>
> It's not about thread safety in terms of 'lockless'. It is the standalone
> patch that fixes many times discussed issue with barriers on
On 2/24/2016 7:47 PM, Ilya Maximets wrote:
>* Wait until it's our turn to add our buffer
> @@ -979,7 +979,7 @@ rte_vhost_dequeue_burst(struct virtio_net *dev, uint16_t
> queue_id,
> entry_success++;
> }
>
> - rte_compiler_barrier();
> + rte_smp_rmb();
On 3/16/2016 8:53 PM, Patrik Andersson R wrote:
> Hello,
>
> When taking a snapshot of a running VM instance, using OpenStack
> "nova image-create", I noticed that one OVS pmd-thread eventually
> failed in DPDK rte_vhost_dequeue_burst() with repeating log entries:
>
>compute-0-6
On 3/16/2016 2:44 PM, Yuanhan Liu wrote:
> We have to reset the virtio net hdr at virtio_enqueue_offload()
> before, due to all mbufs share a single virtio_hdr structure:
>
> struct virtio_net_hdr_mrg_rxbuf virtio_hdr = {{0, }, 0};
>
> foreach (mbuf) {
>
On 3/14/2016 6:56 PM, Richardson, Bruce wrote:
> On Fri, Mar 04, 2016 at 10:19:18AM -0800, Stephen Hemminger wrote:
>> This patch series uses virtio negotiated features to allow for
>> more packets to be queued to host even though the default QEMU/KVM
>> virtio queue is very small 256 elements.
>>
On 3/15/2016 7:14 AM, Thomas Monjalon wrote:
> 2016-01-05 07:16, Xie, Huawei:
>> On 1/5/2016 2:42 PM, Xie, Huawei wrote:
>>> This patch removes the internal lockless enqueue implmentation.
>>> DPDK doesn't support receiving/transmitting packets from/to the same
>&
On 3/1/2016 6:09 PM, Xie, Huawei wrote:
> On 3/1/2016 5:57 PM, Thomas Monjalon wrote:
>> 2016-03-01 08:39, Xie, Huawei:
>>> On 3/1/2016 4:24 PM, Thomas Monjalon wrote:
>>>> 2016-03-01 07:53, Xie, Huawei:
>>>>> On 3/1/2016 3:18 PM, Thomas Monjal
On 3/5/2016 2:17 AM, Stephen Hemminger wrote:
> Resending them now. I don't understand the issue with merge-able header.
> Virtio negotiation is symmetric, if receiver is using merge-able header
> then the transmitter needs to send it also.
Yes, both receiver and transmitter use the same format
On 3/7/2016 4:36 PM, Yuanhan Liu wrote:
> On Mon, Mar 07, 2016 at 07:52:22AM +0000, Xie, Huawei wrote:
>> On 2/18/2016 9:48 PM, Yuanhan Liu wrote:
>>> Current virtio_dev_merge_rx() implementation just looks like the
>>> old rte_vhost_dequeue_burst(), full of twisted
On 2/18/2016 9:48 PM, Yuanhan Liu wrote:
> Current virtio_dev_merge_rx() implementation just looks like the
> old rte_vhost_dequeue_burst(), full of twisted logic, that you
> can see same code block in quite many different places.
>
> However, the logic of virtio_dev_merge_rx() is quite similar to
On 3/7/2016 3:04 PM, Xie, Huawei wrote:
> On 3/7/2016 2:49 PM, Yuanhan Liu wrote:
>> On Mon, Mar 07, 2016 at 06:38:42AM +0000, Xie, Huawei wrote:
>>> On 3/7/2016 2:35 PM, Yuanhan Liu wrote:
>>>> On Mon, Mar 07, 2016 at 06:22:25AM +, Xie, Huawei wrote:
>>&
On 3/7/2016 2:49 PM, Yuanhan Liu wrote:
> On Mon, Mar 07, 2016 at 06:38:42AM +0000, Xie, Huawei wrote:
>> On 3/7/2016 2:35 PM, Yuanhan Liu wrote:
>>> On Mon, Mar 07, 2016 at 06:22:25AM +, Xie, Huawei wrote:
>>>> On 2/18/2016 9:48 PM, Yuanhan Liu wrote:
>>
On 3/7/2016 2:35 PM, Yuanhan Liu wrote:
> On Mon, Mar 07, 2016 at 06:22:25AM +0000, Xie, Huawei wrote:
>> On 2/18/2016 9:48 PM, Yuanhan Liu wrote:
>>> + uint16_t idx = vq->avail->ring[avail_idx & (vq->size - 1)];
>>> + uint32_t vec_id = *vec_i
On 2/18/2016 9:48 PM, Yuanhan Liu wrote:
> + uint16_t idx = vq->avail->ring[avail_idx & (vq->size - 1)];
> + uint32_t vec_id = *vec_idx;
> + uint32_t len= *allocated;
>
There is bug not using volatile to retrieve the avail idx.
On 3/7/2016 12:20 PM, Stephen Hemminger wrote:
> On Thu, 18 Feb 2016 21:49:09 +0800
> Yuanhan Liu wrote:
>
>> +static inline void
>> +copy_virtio_net_hdr(struct vhost_virtqueue *vq, uint64_t desc_addr,
>> +struct virtio_net_hdr_mrg_rxbuf hdr)
>> +{
>> +if (vq->vhost_hlen ==
On 2/18/2016 9:48 PM, Yuanhan Liu wrote:
> + while (1) {
> + /* done with current mbuf, fetch next */
> + if (mbuf_avail == 0) {
> + m = m->next;
> + if (m == NULL)
> + break;
> +
> +
On 2/18/2016 9:48 PM, Yuanhan Liu wrote:
> + if (unlikely(desc->next >= vq->size))
> + goto fail;
desc chains could be forged into a loop then vhost runs the dead loop
until it exhaust all mbuf memory.
On 2/18/2016 9:48 PM, Yuanhan Liu wrote:
> + mbuf_avail = 0;
> + mbuf_offset = 0;
one cs nit, put it at the definition.
On 3/4/2016 10:30 AM, Yuanhan Liu wrote:
> On Thu, Mar 03, 2016 at 05:40:14PM +0000, Xie, Huawei wrote:
>> On 2/18/2016 9:48 PM, Yuanhan Liu wrote:
>>> The current rte_vhost_dequeue_burst() implementation is a bit messy
>> [...]
>>> +
>>> uint16_t
>
On 3/7/2016 10:47 AM, Yuanhan Liu wrote:
> On Mon, Mar 07, 2016 at 02:32:46AM +0000, Xie, Huawei wrote:
>> On 3/4/2016 10:15 AM, Yuanhan Liu wrote:
>>> On Thu, Mar 03, 2016 at 04:30:42PM +, Xie, Huawei wrote:
>>>> On 2/18/2016 9:48 PM, Yuanhan Liu
On 3/4/2016 10:10 AM, Yuanhan Liu wrote:
> On Thu, Mar 03, 2016 at 05:19:42PM +0000, Xie, Huawei wrote:
>> On 2/18/2016 9:48 PM, Yuanhan Liu wrote:
>>> [...]
>> CCed changchun, the author for the chained handling of desc and mbuf.
>> The change makes the c
On 3/4/2016 10:15 AM, Yuanhan Liu wrote:
> On Thu, Mar 03, 2016 at 04:30:42PM +0000, Xie, Huawei wrote:
>> On 2/18/2016 9:48 PM, Yuanhan Liu wrote:
>>> + mbuf_avail = 0;
>>> + mbuf_offset = 0;
>>> + while (desc_avail || (desc->flags & VRING_DESC_F
On 3/4/2016 10:19 AM, Yuanhan Liu wrote:
> On Thu, Mar 03, 2016 at 04:21:19PM +0000, Xie, Huawei wrote:
>> On 2/18/2016 9:48 PM, Yuanhan Liu wrote:
>>> The current rte_vhost_dequeue_burst() implementation is a bit messy
>>> and logic twisted. And you
On 2/18/2016 9:48 PM, Yuanhan Liu wrote:
> Signed-off-by: Yuanhan Liu
Acked-by: Huawei Xie
On 1/14/2016 9:49 PM, Xie, Huawei wrote:
> On 1/6/2016 8:04 PM, Thomas Monjalon wrote:
>> 2016-01-05 08:10, Xie, Huawei:
>>> On 10/26/2015 10:06 PM, Xie, Huawei wrote:
>>>> On 10/19/2015 1:16 PM, Stephen Hemminger wrote:
>>>>> This is a tested vers
On 2/23/2016 12:23 AM, Tom Kiely wrote:
> Hi,
> Sorry I missed the last few messages until now. I'm happy with
> just removing the "if". Kyle, when you say you fixed it, do you mean
> that you will push the patch or have already done so ?
>Thanks,
>Tom
Could you please send the
On 2/18/2016 9:48 PM, Yuanhan Liu wrote:
> The current rte_vhost_dequeue_burst() implementation is a bit messy
[...]
> +
> uint16_t
> rte_vhost_dequeue_burst(struct virtio_net *dev, uint16_t queue_id,
> struct rte_mempool *mbuf_pool, struct rte_mbuf **pkts, uint16_t count)
> {
> -
On 2/18/2016 9:48 PM, Yuanhan Liu wrote:
> [...]
CCed changchun, the author for the chained handling of desc and mbuf.
The change makes the code more readable, but i think the following
commit message is simple and enough.
>
> while (this_desc_is_not_drained_totally || has_next_desc) {
>
On 2/18/2016 9:48 PM, Yuanhan Liu wrote:
> + mbuf_avail = 0;
> + mbuf_offset = 0;
> + while (desc_avail || (desc->flags & VRING_DESC_F_NEXT) != 0) {
> + /* This desc reachs to its end, get the next one */
> + if (desc_avail == 0) {
> + desc
On 2/18/2016 9:48 PM, Yuanhan Liu wrote:
> The current rte_vhost_dequeue_burst() implementation is a bit messy
> and logic twisted. And you could see repeat code here and there: it
> invokes rte_pktmbuf_alloc() three times at three different places!
>
> However, rte_vhost_dequeue_burst() acutally
On 3/1/2016 5:57 PM, Thomas Monjalon wrote:
> 2016-03-01 08:39, Xie, Huawei:
>> On 3/1/2016 4:24 PM, Thomas Monjalon wrote:
>>> 2016-03-01 07:53, Xie, Huawei:
>>>> On 3/1/2016 3:18 PM, Thomas Monjalon wrote:
>>>>> 2016-02-26 09:53, Huawei Xie:
>
On 3/1/2016 4:24 PM, Thomas Monjalon wrote:
> 2016-03-01 07:53, Xie, Huawei:
>> On 3/1/2016 3:18 PM, Thomas Monjalon wrote:
>>> 2016-02-26 09:53, Huawei Xie:
>>>> @@ -1037,8 +1039,11 @@ eth_virtio_dev_init(struct rte_eth_dev *eth_dev)
>>>
On 3/1/2016 3:18 PM, Thomas Monjalon wrote:
> Hi Huawei,
>
> 2016-02-26 09:53, Huawei Xie:
>> --- a/drivers/net/virtio/virtio_ethdev.c
>> +++ b/drivers/net/virtio/virtio_ethdev.c
>> @@ -1,4 +1,5 @@
>> /*-
>> +
> This new line seems useless :)
Sorry, would fix.
>
>> * BSD LICENSE
>> *
>
On 2/29/2016 4:47 PM, David Marchand wrote:
> On Fri, Feb 26, 2016 at 2:53 AM, Huawei Xie wrote:
>> v4 changes:
>> reword the commit message. When we mention kernel driver, emphasizes
>> that it includes UIO/VFIO.
> Annotations should not be part of the commitlog itself.
Do you mean that
On 2/29/2016 12:26 PM, Yuanhan Liu wrote:
> On Fri, Feb 26, 2016 at 02:21:02PM +0530, Santosh Shukla wrote:
>> Check cpuflag macro before using vectored api.
>> -virtio_recv_pkts_vec() uses _sse3__ simd instruction for now so added
>> cpuflag.
>> - Also wrap other vectored freind api ie..
>> 1)
? 2/27/2016 1:47 AM, Xie, Huawei ??:
> Use RTE_KDRV_NONE to indicate that kernel driver(including UIO/VFIO)
> isn't manipulating the device.
Thomas, could you kindly help change manipulating->managing? I have
changed others per Panu's suggestion but missed this.
On 2/26/2016 4:56 PM, Olivier MATZ wrote:
>
> On 02/23/2016 06:35 AM, Xie, Huawei wrote:
>>>> Also, it would be nice to have a simple test function in
>>>> app/test/test_mbuf.c. For instance, you could update
>>>> test_one_pktmbuf() to take a mbuf point
On 2/26/2016 4:41 PM, David Marchand wrote:
> On Fri, Feb 26, 2016 at 7:09 AM, Xie, Huawei wrote:
>> On 2/24/2016 8:45 PM, Thomas Monjalon wrote:
>>>> Huawei Xie (4):
>>>> eal: make the comment more accurate
>>>> eal: set kdrv to RTE_
On 2/26/2016 4:29 PM, David Marchand wrote:
> On Fri, Feb 26, 2016 at 3:23 AM, Yuanhan Liu
> wrote:
>> Mauricio, thanks for the testing and report.
>>
>> On Thu, Feb 25, 2016 at 02:30:18PM +0100, David Marchand wrote:
>>> >From the logs, I would say I broke uio_pci_generic since we are in
>>>
On 2/24/2016 9:23 PM, Ananyev, Konstantin wrote:
> Hi Panu,
>
>> -Original Message-
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Panu Matilainen
>> Sent: Wednesday, February 24, 2016 12:12 PM
>> To: Xie, Huawei; Olivier MATZ; dev at dpdk.o
On 2/24/2016 8:45 PM, Thomas Monjalon wrote:
>> Huawei Xie (4):
>> eal: make the comment more accurate
>> eal: set kdrv to RTE_KDRV_NONE if kernel driver isn't manipulating the
>> device.
>> virtio: return 1 to tell the kernel we don't take over this device
>> virtio: check if kernel
On 2/24/2016 1:07 PM, Ilya Maximets wrote:
> On 23.02.2016 08:56, Xie, Huawei wrote:
>> On 2/22/2016 6:16 PM, Thomas Monjalon wrote:
>>> 2016-02-22 02:07, Xie, Huawei:
>>>> On 2/19/2016 5:05 PM, Ilya Maximets wrote:
>>>>> On 19.02.2016 11:36, Xie, Huawe
m
>
> On 02/18/2016 02:03 PM, Kyle Larose wrote:
>> On Tue, Jan 5, 2016 at 2:13 AM, Xie, Huawei
>> wrote:
>>> On 12/17/2015 7:18 PM, Tom Kiely wrote:
>>>>
>>>> On 11/25/2015 05:32 PM, Xie, Huawei wrote:
>>>>> On 11/13/2015 5:33 PM, Tom
On 2/22/2016 6:16 PM, Thomas Monjalon wrote:
> 2016-02-22 02:07, Xie, Huawei:
>> On 2/19/2016 5:05 PM, Ilya Maximets wrote:
>>> On 19.02.2016 11:36, Xie, Huawei wrote:
>>>> On 2/19/2016 3:10 PM, Yuanhan Liu wrote:
>>>>> On Fri, Feb 19, 2016 at 09:32:4
On 2/22/2016 10:52 PM, Xie, Huawei wrote:
> On 2/4/2016 1:24 AM, Olivier MATZ wrote:
>> Hi,
>>
>> On 01/27/2016 02:56 PM, Panu Matilainen wrote:
>>> Since rte_pktmbuf_alloc_bulk() is an inline function, it is not part of
>>> the library ABI and should not
On 2/4/2016 1:24 AM, Olivier MATZ wrote:
> Hi,
>
> On 01/27/2016 02:56 PM, Panu Matilainen wrote:
>>
>> Since rte_pktmbuf_alloc_bulk() is an inline function, it is not part of
>> the library ABI and should not be listed in the version map.
>>
>> I assume its inline for performance reasons, but
On 2/19/2016 5:05 PM, Ilya Maximets wrote:
> On 19.02.2016 11:36, Xie, Huawei wrote:
>> On 2/19/2016 3:10 PM, Yuanhan Liu wrote:
>>> On Fri, Feb 19, 2016 at 09:32:43AM +0300, Ilya Maximets wrote:
>>>> Signed-off-by: Ilya Maximets
>&g
On 2/19/2016 2:42 PM, Yuanhan Liu wrote:
> On Fri, Feb 19, 2016 at 10:16:42AM +0530, Santosh Shukla wrote:
>> On Tue, Feb 16, 2016 at 8:35 AM, Yuanhan Liu
>> wrote:
>>> On Mon, Feb 15, 2016 at 04:48:36PM +0530, Santosh Shukla wrote:
Hi Yuanhan,
On Mon, Feb 15, 2016 at 4:27 PM,
On 2/19/2016 3:10 PM, Yuanhan Liu wrote:
> On Fri, Feb 19, 2016 at 09:32:43AM +0300, Ilya Maximets wrote:
>> Signed-off-by: Ilya Maximets
>> ---
>> doc/guides/prog_guide/thread_safety_dpdk_functions.rst | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git
On 2/19/2016 3:31 PM, Ilya Maximets wrote:
> On 19.02.2016 10:06, Yuanhan Liu wrote:
>> On Fri, Feb 19, 2016 at 09:32:41AM +0300, Ilya Maximets wrote:
>>> Array of buf_vector's is just an array for temporary storing information
>>> about available descriptors. It used only locally in
On 1/28/2016 10:44 AM, Tetsuya Mukawa wrote:
> On 2016/01/27 19:03, Xie, Huawei wrote:
>> On 1/21/2016 7:09 PM, Tetsuya Mukawa wrote:
>>> + /* Set BAR region */
>>> + for (i = 0; i < NB_BAR; i++) {
>>> + switch (dev->bar[i].typ
On 1/14/2016 9:29 PM, Santosh Shukla wrote:
> Hi,
>
> This v4 patch uses vfio-noiommu-way to access virtio-net pci interface.
> Tested for arm64 thunderX platform. Patch builds for
> x86/i386/arm/armv8/thunderX. Tested with testpmd application.
Hi Shukla:
I would take two week's leave from
1 - 100 of 474 matches
Mail list logo
