From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-11.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CC449C2B9F7 for ; Wed, 26 May 2021 11:51:18 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id AB82261132 for ; Wed, 26 May 2021 11:51:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233328AbhEZLwp (ORCPT ); Wed, 26 May 2021 07:52:45 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:20124 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232944AbhEZLvG (ORCPT ); Wed, 26 May 2021 07:51:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1622029771; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=4n0qlKXB1bnPoNluf4mjZlVoqIwiQZkhDutOAoVJjSM=; b=OAO69Nh6TwgMYOjNCGYDXn4VRTVKa771BtTj5CpSexvHH9qhLypHMGDJZKH6CdVieRVzKx 3U+dVLFbKhdB8dH4Y5DyPdVEi8yxUHCFctJXCj9FT4bViCuh9grghKmen5QWwII6yIQgdh xG4Xaf5/G6TjBFRk5vCfB5X+XL62zHY= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-511-4EOmWYC1MZGc--gEK8i0Fw-1; Wed, 26 May 2021 07:49:25 -0400 X-MC-Unique: 4EOmWYC1MZGc--gEK8i0Fw-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 96786189C446; Wed, 26 May 2021 11:49:22 +0000 (UTC) Received: from carbon (unknown [10.36.110.39]) by smtp.corp.redhat.com (Postfix) with ESMTP id 74B6210074E0; Wed, 26 May 2021 11:49:11 +0000 (UTC) Date: Wed, 26 May 2021 13:49:10 +0200 From: Jesper Dangaard Brouer To: John Fastabend Cc: Alexander Lobakin , Toke =?UTF-8?B?SMO4?= =?UTF-8?B?aWxhbmQtSsO4cmdlbnNlbg==?= , Saeed Mahameed , "Raczynski, Piotr" , "Zhang, Jessica" , "Kubiak, Marcin" , "Joseph, Jithu" , "kurt@linutronix.de" , "Maloor, Kishen" , "Gomes, Vinicius" , "Brandeburg, Jesse" , "Swiatkowski, Michal" , "Plantykow, Marta A" , "Ong, Boon Leong" , "Desouza, Ederson" , "Song, Yoong Siang" , "Czapnik, Lukasz" , bpf@vger.kernel.org, brouer@redhat.com Subject: Re: AF_XDP metadata/hints Message-ID: <20210526134910.1c06c5d8@carbon> In-Reply-To: <60add3cad4ef0_3b75f2086@john-XPS-13-9370.notmuch> References: <20210507131034.5a62ce56@carbon> <20210510185029.1ca6f872@carbon> <20210512102546.5c098483@carbon> <7b347a985e590e2a422f837971b30bd83f9c7ac3.camel@nvidia.com> <20210521153110.207cb231@carbon> <1426bc91c6c6ee3aaf3d85c4291a12968634e521.camel@kernel.org> <87lf85zmuw.fsf@toke.dk> <20210525142027.1432-1-alexandr.lobakin@intel.com> <60add3cad4ef0_3b75f2086@john-XPS-13-9370.notmuch> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org On Tue, 25 May 2021 21:51:22 -0700 John Fastabend wrote: > Separate the config of hardware from the BPF infrastructure these > are two separate things. I fully agree. How should we handle existing config interfaces? Let me give some concrete examples. Today there are multiple existing interfaces to enable/disable NIC hardware features that change what is available to put in our BTF-layout. E.g. changing if VLAN is in descriptor: # ethtool -K ixgbe1 rx-vlan-offload off # ethtool -k ixgbe1 | grep vlan-offload rx-vlan-offload: off tx-vlan-offload: on The timestamping features can be listed by ethtool -T (see below signature), but it is a socket option that enable[1] these (see SO_TIMESTAMPNS or SOF_TIMESTAMPING_RX_HARDWARE). Or tuning RSS hash fields: [2] https://github.com/stackpath/rxtxcpu/blob/master/Documentation/case-studies/observing-rss-on-ixgbe-advanced-rss-configuration-rss-hash-fields.md I assume we need to stay compatible and respect the existing config interfaces, right? Should we simple leverage existing interfaces? E.g. tcpdump --time-stamp-type=adapter_unsynced could simple enable the BTF-layout that contains the RX-timestamp. This would make it avail to XDP/AF_XDP and the xdp_frame can also create a SKB with the timestamp. [1] https://www.kernel.org/doc/html/latest/networking/timestamping.html -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat LinkedIn: http://www.linkedin.com/in/brouer # ethtool -T ixgbe1 Time stamping parameters for ixgbe1: Capabilities: hardware-transmit software-transmit hardware-receive software-receive software-system-clock hardware-raw-clock PTP Hardware Clock: 7 Hardware Transmit Timestamp Modes: off on Hardware Receive Filter Modes: none ptpv1-l4-sync ptpv1-l4-delay-req ptpv2-event # ethtool -T igc1 Time stamping parameters for igc1: Capabilities: hardware-transmit software-transmit hardware-receive software-receive software-system-clock hardware-raw-clock PTP Hardware Clock: 1 Hardware Transmit Timestamp Modes: off on Hardware Receive Filter Modes: none all