From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 22783437C5; Fri, 29 Dec 2023 22:29:39 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 9EA164026F; Fri, 29 Dec 2023 22:29:38 +0100 (CET) Received: from mail-oi1-f174.google.com (mail-oi1-f174.google.com [209.85.167.174]) by mails.dpdk.org (Postfix) with ESMTP id E611840265 for ; Fri, 29 Dec 2023 22:29:36 +0100 (CET) Received: by mail-oi1-f174.google.com with SMTP id 5614622812f47-3bba50cd318so4302325b6e.0 for ; Fri, 29 Dec 2023 13:29:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uconn-edu.20230601.gappssmtp.com; s=20230601; t=1703885376; x=1704490176; darn=dpdk.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=7g0DOWJYmKBAlF0ripc5NPkbqin1eYpvAoM+jpUTvYQ=; b=KRAC1DHkxg9K6qecgQaaQ/H2r7xUQD/DG/OGygsf4wsGLUtiU7JFbCN6QAD45wiWdD /H3MTt1eaxg9BUE9h7CwfrAvmxhN6U+81ZHYKpF+//3Aj/BqE5AVMYW+MJ89eRAGNZcB Glht3CncQFVC53YBQm2/4iEbIGqVBpGDX39nNkNn00NsI9r3iylsda6QqqXaznkAwn1T wDL6W6viBQFtNV1lkAqSED3YwPyzBqv0LA1HeXlLrYLvT71PCXG51a38lVkZOxUR7VEA tog69lwNb2dhn/jYWxYFvTe+qvBXxQdRjAnFSjnlUa/aIgk81wqf7m7CKr+zQoXydAUk yTog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703885376; x=1704490176; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=7g0DOWJYmKBAlF0ripc5NPkbqin1eYpvAoM+jpUTvYQ=; b=dSLPKPHb8zm2Vjd0C4caBVZxl+SbSLlcDC+Z6zDpe+7o5FIiMBLZva9fe0c5Y/Il3Y uMbfaE9XWWZcGS4spb0duLpRJogMgWnS8g+/7CjZb3DWMMnsGNK/dEt3F5xwXSlsrMCD wqrWD18w9D/z346P9WmheRtGgbmmiQGD/XUQG4xOuuL7RHQTlbdv1lQQtxy/Y/cDnPPO otfERsfB8NnokVaLvFY1tzP/AU5Ko5FrC/rh6TyK2NzYLixIsqMRrup57D0YUs38ZwUN IH62oTXuk/Ko0lBLEjy2zOnRIvyjrGYYCyP82r1a75MQaHaztGEdP+wHKBM0Mr+iNMOd /RdQ== X-Gm-Message-State: AOJu0YzEuAEc6sxZnz/V/OgcsO8X2ieF/hXvV/cqP4oUMJYc0PIj93ri kDsJRbY5h24O0+goExZ04lhsN0FA/el+PA== X-Google-Smtp-Source: AGHT+IGczEBUaym71wCAaW01hANtF7wGsRZ8g7F4CNruU6RiEiIeijHAYIi/tXrms0XG7ScxUq73VQ== X-Received: by 2002:a05:6808:2091:b0:3bb:e1ba:d71b with SMTP id s17-20020a056808209100b003bbe1bad71bmr1672954oiw.76.1703885375961; Fri, 29 Dec 2023 13:29:35 -0800 (PST) Received: from localhost.localdomain ([137.99.252.108]) by smtp.gmail.com with ESMTPSA id ay35-20020a05622a22a300b0042807e3b664sm777263qtb.67.2023.12.29.13.29.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 29 Dec 2023 13:29:35 -0800 (PST) From: Chuanyu Xue To: simei.su@intel.com Cc: beilei.xing@intel.com, chuanyu.xue@uconn.edu, dev@dpdk.org, qi.z.zhang@intel.com, wenzhuo.lu@intel.com Subject: RE: [PATCH] net/e1000: support launchtime feature Date: Fri, 29 Dec 2023 16:29:34 -0500 Message-Id: <20231229212934.98657-1-chuanyu.xue@uconn.edu> X-Mailer: git-send-email 2.25.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org >> >> >> +static int >> >> +eth_igb_read_clock(__rte_unused struct rte_eth_dev *dev, uint64_t >> >> +*clock) { >> >> + uint64_t systime_cycles; >> >> + struct e1000_adapter *adapter = dev->data->dev_private; >> >> + >> >> + systime_cycles = igb_read_systime_cyclecounter(dev); >> >> + uint64_t ns = rte_timecounter_update(&adapter->systime_tc, >> >> systime_cycles); >> > >> >Do you also run "ptp timesync" when testing this launchtime feature? >> > >> >> I used `rte_eth_timesync_enable` function during the test. I am not familiar >> with the `ptp timesync` in DPDK. If you are referring to something else, could >> you please guide me on how to test it? > >Do you use your own application or DPDK application to test this launchtime feature, >for example, dpdk testpmd? Yes, I used my own application to test it. The benefit of launch time feature in boundable delay and jitter is significant compared with when it is disabled. Specifically, my app periodically calls `rte_eth_tx_burst` with `rte_dynfield_timestamp` field on talker, and compares whether the receiving time in NIC hardware timestamp on listener is as expected. Talker and listener are directly connected by a RJ45 cable, both installed with i210 NIC. The feature works perfect in my test. I also tested it with testpmd with `txtimes` config. However it seems there is an issue in testpmd. Specifically the tx_only mode sends packets as fast as possible, results in an increasing gap between the current time and the scheduled transmission time. Based on i210 NIC sheet Sec 7.2.2.2.3, the launch time should be within (current_time, current time + 0.5 Sec), thus most of tx packets are not scheduled. I got the similar test results with dpdk igc driver which already implemeted launch time feature. Following is how I try to test with testpmd. Please let me know if I did something wrong. sudo ./dpdk-testpmd -- -i --forward-mode=txonly testpmd> port stop 0 testpmd> set burst 1 testpmd> set txtimes 100000000,0 testpmd> port config 0 tx_offload send_on_timestamp on testpmd> port start 0 testpmd> start > >> +-----------+---------------+---------------+---------------+---------------+---------------+ >> | 1G | 16880 | 16880 | 16880 | 16880 >> | 16880 | >> +-----------+---------------+---------------+---------------+---------------+---------------+ >> >> Any suggestions here? Is it supposed to be embedded directly here or left to >> the application level to compensate? I can fix it accordingly. > >I think it can be put here directly just as you do. Got it. Will keep this delay compensiation here and revise it in the next batch version.