Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3954213imu; Tue, 18 Dec 2018 06:55:02 -0800 (PST) X-Google-Smtp-Source: AFSGD/UArWznjPFfKuk8y2OHYYscyxLJMMLr6YOVv6Q4vHAtCX8WRhXWvs8ZJvA8PwYc2M7t4Oly X-Received: by 2002:a63:2643:: with SMTP id m64mr15766834pgm.35.1545144902476; Tue, 18 Dec 2018 06:55:02 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1545144902; cv=none; d=google.com; s=arc-20160816; b=S1ACKceA6zUB79LxBpXV0a99VX8Z4GX4ebqeUZlG2mzlQJ1j2ZL6kNrV3ifbEsuh9E 3vxm74Rltgce+pGfSSbqQhVTxdNZXJcUhwFsY+0QCcd93mMbJ49Hf1XwqAvtMOMYBtBT 0wiyzJsrb/JTKD8Pl3gz0h2Bv6NN5XYOe6H1169zui73yaIDa9QP5h/TvGuak9au0lPY 35uH2DYRPXEk6MrIkqJQfleET5+SVIjNeTrRLuQO/sh48QMV7jkbxCqFviSP8/hZqZ5O 0Ve4ibMLCZo1IR0D8mKI9pjavCLE8BsV7U6FUvYET4T35zzLXNt4oLVUwANDt//sH1ow G0tA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=QvYnceKH6XUGRvylP7YxlUv895BZWOE7b1gsAIS8ouY=; b=kHfDYCl99BJbJIDOsQydbXGvoveFX22OwFhaC4LqIN5OW3Y8ZpQnI9I0sus9q9Wx9s NGMhgA2M8s8e4M9pPcLEuW1DSaqcUvcoD3hY2Ajj80MePVIJ87AG2p26zZs93XCK+rDk nZ61ze4RDQIMq+zFA8FXKwLL7EM8JpkINHCzuSrEUoeOtgqWc73F2VuTBJ5DVlFq2alK b6ckKVDnemVYZkMCaifV+JjMfjLcZdUIQXzIs+Ds+GoeErlV1R4PGC9m8+Kt2l578vau 8WC7hzoILkDhJPgPgu/fPfiT5WX2njALJH07jT8xuX4SMlXygwmJVkKEXn8B372JgzWL 4SFA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b="R3CG8O/L"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t65si14506038pfd.246.2018.12.18.06.54.46; Tue, 18 Dec 2018 06:55:02 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b="R3CG8O/L"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726674AbeLROxy (ORCPT + 99 others); Tue, 18 Dec 2018 09:53:54 -0500 Received: from mail.kernel.org ([198.145.29.99]:56418 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726426AbeLROxy (ORCPT ); Tue, 18 Dec 2018 09:53:54 -0500 Received: from [192.168.1.112] (c-24-9-64-241.hsd1.co.comcast.net [24.9.64.241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 935F521850; Tue, 18 Dec 2018 14:53:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1545144833; bh=2dpshEut2yHTzIQ57or8Rxgx0kWdLvyD3iA0La9ewEs=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=R3CG8O/LI0KI9eYItvy+ZC4rKxegixVczykTeTgIgf3IkT77C58hN2I9nBYK+c76r aS+UjBDVCyTyazYXTFZjpwJa/zhADG5ePDqVZ4b/byROP1JuEjKghBywMXOCSTyVOo C70Wn6rrSfY3ORzRU9AaJk1W8tfw3VOPkbzvrZcM= Subject: Re: selftests/net: udpgso: LTS kernels supportability ? To: Rafael David Tinoco Cc: "David S. Miller" , netdev@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org, Willem de Bruijn , Dan Rue , Anders Roxell , shuah References: <1d2c9a10-6caf-49ff-b921-8b93dbe96f78@kernel.org> <1de7a003-0aac-1f4f-b836-267136e30a0a@linaro.org> From: shuah Message-ID: Date: Tue, 18 Dec 2018 07:53:36 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <1de7a003-0aac-1f4f-b836-267136e30a0a@linaro.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12/18/18 4:37 AM, Rafael David Tinoco wrote: > On 12/17/18 4:42 PM, shuah wrote: >> Hi Rafael, >> >> On 12/17/18 10:53 AM, Rafael David Tinoco wrote: >>> Shuah, >>> >>> I was recently investigating some errors coming out of our functional >>> tests and we, Dan and I, came up with a discussion that might not be new >>> for you, but, interests us, in defining how to better use kselftests as >>> a regression mechanism/tool in our LKFT (https://lkft.linaro.org). >>> >>> David / Willem, >>> >>> I'm only using udpgso as an example for what I'd like to ask Shuah. Feel >>> free to jump in in the discussion if you think its worth. >>> >>> All, >>> >>> Regarding: udpgso AND https://bugs.linaro.org/show_bug.cgi?id=3980 >>> >>> udpgso tests are failing in kernels bellow 4.18 because of 2 main >>> reasons: >>> >>> 1) udp4_ufo_fragment does not seem to demand the GSO SKB to be > than >>> the MTU for older kernels (4th test case in udpgso.c). >>> >>> 2) setsockopt(...UDP_SEGMENT) support is not present for older kernels. >>> (commits "udp: generate gso with UDP_SEGMENT" and its fixes seem to be >>> needed). >> >> This case is easy right? Based on the test output below , I can see that >> the failure is due to >> >> ./udpgso: setsockopt udp segment: Protocol not available. setsockopt() >> is returning an error to clearly indicate that this options isn't >> supported. This will be a test change to say test is a skip as opposed >> to fail. > > You referred to (2). (1) isn't that straightforward. > >> We have a solution for this - test should SKIP as opposed to FAIL. >> >>> With that explained, finally the question/discussion: >>> >>> Shouldn't we enforce a versioning mechanism for tests that are testing >>> recently added features ? I mean, some of the tests inside udpgso >>> selftest are good enough for older kernels... >> >> Right - we do have generic way to handle that by detecting if feature is >> supported and skip instead of using Kernel version which is going to be >> hard to maintain. > > You can't distinguish case (1) failures between real failures OR older > kernel behaving differently then testcase expects. > >>> >>> But, because we have no control over "kernel features" and "supported >>> test cases", we, Linaro, have to end up blacklisting all selftests that >>> have new feature oriented tests, because one or two test cases only. >>> Can you share the blacklisted tests? thanks, -- Shuah