From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-f68.google.com (mail-lf0-f68.google.com [209.85.215.68]) by dpdk.org (Postfix) with ESMTP id 332761B5CE for ; Tue, 26 Jun 2018 15:35:54 +0200 (CEST) Received: by mail-lf0-f68.google.com with SMTP id n24-v6so17441235lfh.3 for ; Tue, 26 Jun 2018 06:35:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=XJ+p2u4NIdmvJjC62Tmt1vgjaxYtYKDcCrcuZBv8JAI=; b=fAbm4RnV6e0G4BlwK/24yEnSQKa7E6fJgu6QqiidINF1Aoio81x7i3GEFrzcUzX9M/ /1nXltDrqAJOc6WyDb/2LGx1lBzw0u6RLmLpSYjYIkAv1OjS5/afn5UNKH04g7/NS4hm yjP9lJtpRp7sOqqr+T/xv/vzCnNRaqjW0H5jo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=XJ+p2u4NIdmvJjC62Tmt1vgjaxYtYKDcCrcuZBv8JAI=; b=loDx4ag8LaWU1CMS2EB57Z2G/Hbrmhhz1WxAkufyypq1OLfWuHgozhMIQBoooV/yUz UnbiUSzZurM5oKdaxJaR/WfeDvQ8i/BieULlNKlfbv1FZbnd+pfeyy9ZdNRYo293tiHs XDcOSc6F1qB6FRQ2hkOR69BRQM7RznC1KJr+jdH2kndgyNXqEwkG4PJEfl0wKovedFgH 1cxD9dmEHELbMdxSFcc4Kp5hala7Ly3pvXAARZNkaPQBaXI0mUnn/4Rc1olEBmhDdflS XwA7zXkAEgXAjFJ5MmdzNGrEoTUnS9McYWqylcavCc/jP4AQ8M67bnihoOvl3XbNBCrJ gvVA== X-Gm-Message-State: APt69E1XPyHItL0k03MhQQBQB3z1LNxf4nqlqZGPymAtK/+xuEEywIIh rNZUutRp0Tu65vbP1PcgNn3Nqw== X-Google-Smtp-Source: AAOMgpdif4az7y7GLHOpPffZq1Ut8hEUS67d5h6fJBEC4IWUmwHC0Os2ikxXHDgg4sbeXH7We2gEKQ== X-Received: by 2002:a19:274e:: with SMTP id n75-v6mr1331724lfn.14.1530020153792; Tue, 26 Jun 2018 06:35:53 -0700 (PDT) Received: from [192.168.1.66] ([95.165.131.83]) by smtp.gmail.com with ESMTPSA id b204-v6sm361316lfb.12.2018.06.26.06.35.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Jun 2018 06:35:53 -0700 (PDT) To: "Elo, Matias (Nokia - FI/Espoo)" , "harry.van.haaren@intel.com" Cc: "dev@dpdk.org" , "jerin.jacob@caviumnetworks.com" References: <09B2B474-8558-4EE6-BB26-460EF8C89909@nokia.com> From: Maxim Uvarov Message-ID: <3a3a5a4f-f337-2495-969e-4e9223b66342@linaro.org> Date: Tue, 26 Jun 2018 16:35:51 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <09B2B474-8558-4EE6-BB26-460EF8C89909@nokia.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Subject: Re: [dpdk-dev] [Bug 60] rte_event_port_unlink() causes subsequent events to end up in wrong port X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 13:35:54 -0000 Hello, is there any progress on this? Thank you, Maxim. On 19.06.2018 12:20, Elo, Matias (Nokia - FI/Espoo) wrote: >> I think this should handle the unlink case you mention, however perhaps you have identified a genuine bug. If you have more info or a sample config / app that easily demonstrates the issue that would help reproduce/debug here? > > Hi Harry, > > The bug report includes a simple test application for demonstrating the issue. I've done some further digging and the following simple patch seems to fix the issue of events ending up in wrong ports. > > > diff --git a/drivers/event/sw/sw_evdev_scheduler.c b/drivers/event/sw/sw_evdev_scheduler.c > index 8a2c9d4f9..57298345d 100644 > --- a/drivers/event/sw/sw_evdev_scheduler.c > +++ b/drivers/event/sw/sw_evdev_scheduler.c > @@ -79,9 +79,11 @@ sw_schedule_atomic_to_cq(struct sw_evdev *sw, struct sw_qid * const qid, > int cq = fid->cq; > > if (cq < 0) { > - uint32_t cq_idx = qid->cq_next_tx++; > - if (qid->cq_next_tx == qid->cq_num_mapped_cqs) > + uint32_t cq_idx; > + if (qid->cq_next_tx >= qid->cq_num_mapped_cqs) > qid->cq_next_tx = 0; > + cq_idx = qid->cq_next_tx++; > + > cq = qid->cq_map[cq_idx]; > > /* find least used */ > @@ -168,9 +170,11 @@ sw_schedule_parallel_to_cq(struct sw_evdev *sw, struct sw_qid * const qid, > do { > if (++cq_check_count > qid->cq_num_mapped_cqs) > goto exit; > - cq = qid->cq_map[cq_idx]; > - if (++cq_idx == qid->cq_num_mapped_cqs) > + > + if (cq_idx >= qid->cq_num_mapped_cqs) > cq_idx = 0; > + cq = qid->cq_map[cq_idx++]; > + > } while (rte_event_ring_free_count( > sw->ports[cq].cq_worker_ring) == 0 || > sw->ports[cq].inflights == SW_PORT_HIST_LIST); > @@ -251,6 +255,9 @@ sw_schedule_qid_to_cq(struct sw_evdev *sw) > if (iq_num >= SW_IQS_MAX) > continue; > > + if (qid->cq_num_mapped_cqs == 0) > + continue; > + > uint32_t pkts_done = 0; > uint32_t count = iq_ring_count(qid->iq[iq_num]); > > > However, events from atomic/ordered queues may still end up getting stuck when unlinking (scheduled back to unlinked port). In case of atomic queues the problem seems to be related to (struct sw_fid_t *)fid->cq fields being invalid. With ordered queues events get stuck in reorder buffer. > > -Matias >