From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Atkins Subject: Re: [PATCH 0/3] null driver improvements for testability Date: Tue, 23 Feb 2016 15:24:35 +0000 Message-ID: <56CC79B3.80801@brocade.com> References: <1454084293-5722-1-git-send-email-patkins@brocade.com> <1600067.TyQ2MXbqf2@xps13> <56AB97BE.9030106@brocade.com> <20160217172336.GC11736@bricha3-MOBL3> <56C5B6EE.9030805@brocade.com> <20160223152150.GB17644@bricha3-MOBL3> Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Cc: dev@dpdk.org To: Bruce Richardson Return-path: Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by dpdk.org (Postfix) with ESMTP id B05402B86 for ; Tue, 23 Feb 2016 16:24:46 +0100 (CET) In-Reply-To: <20160223152150.GB17644@bricha3-MOBL3> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 23/02/16 15:21, Bruce Richardson wrote: > On Thu, Feb 18, 2016 at 12:19:58PM +0000, Paul Atkins wrote: >> >> On 17/02/16 17:23, Bruce Richardson wrote: >>> On Fri, Jan 29, 2016 at 04:47:58PM +0000, Paul Atkins wrote: >>>> Hi Thomas, >>>> >>>> On 29/01/16 16:31, Thomas Monjalon wrote: >>>>> Hi Paul, >>>>> >>>>> 2016-01-29 16:18, Paul Atkins: >>>>>> This patchset adds functionality to the null driver help when testing >>>>>> a dataplane that uses dpdk. The idea is that the the dataplane can >>>>>> have multiple null interfaces attached, and each of theses can be >>>>>> assigned a mac address. Packets can then be injected into the null >>>>>> drivers by adding them to a ring, giving the application complete >>>>>> control of the packets that arrive. Packets that are sent by a null >>>>>> driver can be stored on a ring, where the application can pick them up >>>>>> and verify it is what was expected. To allow the application to know >>>>>> when packets have been pulled of the rx ring, counters of the number of >>>>>> times an rx poll has been made are kept, and these can be retrieved via >>>>>> the existing APIs. >>>>> I have not read your code, just read this description. >>>>> It sounds like being a ring PMD. Have you already checked it? >>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__dpdk.org_browse_dpdk_tree_drivers_net_ring_rte-5Feth-5Fring.c&d=CwICAg&c=IL_XqQWOjubgfqINi2jTzg&r=45ezphVDEm8OnEpH-fLWdXvR3RneLhhNZRDLQRgR6LY&m=wJLO24XFe_B0nZve6mkvocCt7fQWo3PULCTWxrC8rZk&s=bIWycJrY-PYgzkQsBeRfkl8JCHFcxRAHhHDrqRSzHYs&e= >>>> I hadn't seen the ring PMD. I will have a look at it and see if I can make >>>> it do what i need. >>>> >>>> thanks, >>>> Paul >>> Hi Paul, >>> >>> any update on this. Your patches are still showing as pending in patchwork, but >>> if ring pmd is more what need, we can set these patches aside as unneeded, and >>> remove them from the patchwork merge backlog. >> Hi Bruce, >> >> Sorry for the delay. The patchset adds 3 things: assigning a mac addr to >> the null pmd, adding the rings to the null pmd and adding xstats for how >> many times the null pmd has been polled. I could move to using the ring >> pmd, but I would still need the other 2 parts (mac addr and stats). It >> seems like the ring pmd shouldn't really have these two extra things added, >> but i could do that if it that is preferred over what is in the current >> patchset. >> > Adding a mac address to be reported by the ring PMD should not be a problem. > Having a stat that tracks polls might be depending on how it is done - if it > uses an atomic, as in this patchset, it would problematic as it would add a > severe performance hit for the SP/SC ring case. However, you could get around > that by copying what is already done in the PMD for tracking packet counts. > > Overall, though, it seems that it might be worthwhile doing the work to extend > the ring pmd rather than turning the null pmd into a second ring one. Ok, I will make those changes and resubmit - you can mark the current patches as unneeded. thanks, Paul > > Regards, > /Bruce