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 9B5B0A050B; Thu, 7 Apr 2022 08:21:40 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 772A140689; Thu, 7 Apr 2022 08:21:40 +0200 (CEST) Received: from szxga08-in.huawei.com (szxga08-in.huawei.com [45.249.212.255]) by mails.dpdk.org (Postfix) with ESMTP id 52B0C4014F for ; Thu, 7 Apr 2022 08:21:38 +0200 (CEST) Received: from kwepemi500012.china.huawei.com (unknown [172.30.72.53]) by szxga08-in.huawei.com (SkyGuard) with ESMTP id 4KYrqS2BMmz1HBL8; Thu, 7 Apr 2022 14:21:08 +0800 (CST) Received: from [10.67.103.128] (10.67.103.128) by kwepemi500012.china.huawei.com (7.221.188.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Thu, 7 Apr 2022 14:21:35 +0800 Subject: Re: [PATCH] kni: fix device address set To: Stephen Hemminger CC: , , References: <20220406082213.45750-1-humin29@huawei.com> <20220406081700.4aa2d9a7@hermes.local> <40f8ce34-982c-d96f-b1a7-d8381c36dcf1@huawei.com> <20220406201828.6eac9e56@hermes.local> From: "Min Hu (Connor)" Message-ID: Date: Thu, 7 Apr 2022 14:21:35 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1 MIME-Version: 1.0 In-Reply-To: <20220406201828.6eac9e56@hermes.local> Content-Type: text/plain; charset="gbk"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.67.103.128] X-ClientProxiedBy: dggems704-chm.china.huawei.com (10.3.19.181) To kwepemi500012.china.huawei.com (7.221.188.12) X-CFilter-Loop: Reflected 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 Hi, ÔÚ 2022/4/7 11:18, Stephen Hemminger дµÀ: > On Thu, 7 Apr 2022 08:44:23 +0800 > "Min Hu (Connor)" wrote: > >> Hi, Stephen, >> I think this is a good option, but the macro definition is like: >> +#if LINUX_VERSION_CODE < KERNEL_VERSION(3, 14, 0) >> +#define ether_addr_copy(dst, src) memcpy(dst, src, ETH_ALEN) >> +#endif > > Minimal supported DPDK version is 4.4 now. So this is not a problem. I did not catch your meaning. I think this is a problem. Acording to current definition, we can only use "ether_addr_copy" on linux platform of version 3.13.0(or below). How about the situaction on other linux version, like 3.14.0(or upper)? > > Note: 4.4 kernel reached end of support window in Febrary 2022. > It is supported by the SLTS project but it would be unwise > to use later DPDK on a kernel that is stuck being supported until 2036. > > Apparently my patch to update it to current LTS 4.9 is sitting > stuck in patchwork. > . >