bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jesper Dangaard Brouer <brouer@redhat.com>
To: John Fastabend <john.fastabend@gmail.com>
Cc: "Alexander Lobakin" <alexandr.lobakin@intel.com>,
	"Toke Høiland-Jørgensen" <toke@redhat.com>,
	"Saeed Mahameed" <saeed@kernel.org>,
	"Raczynski, Piotr" <piotr.raczynski@intel.com>,
	"Zhang, Jessica" <jessica.zhang@intel.com>,
	"Kubiak, Marcin" <marcin.kubiak@intel.com>,
	"Joseph, Jithu" <jithu.joseph@intel.com>,
	"kurt@linutronix.de" <kurt@linutronix.de>,
	"Maloor, Kishen" <kishen.maloor@intel.com>,
	"Gomes, Vinicius" <vinicius.gomes@intel.com>,
	"Brandeburg, Jesse" <jesse.brandeburg@intel.com>,
	"Swiatkowski, Michal" <michal.swiatkowski@intel.com>,
	"Plantykow, Marta A" <marta.a.plantykow@intel.com>,
	"Ong, Boon Leong" <boon.leong.ong@intel.com>,
	"Desouza, Ederson" <ederson.desouza@intel.com>,
	"Song, Yoong Siang" <yoong.siang.song@intel.com>,
	"Czapnik, Lukasz" <lukasz.czapnik@intel.com>,
	bpf@vger.kernel.org, brouer@redhat.com
Subject: Re: AF_XDP metadata/hints
Date: Wed, 26 May 2021 13:49:10 +0200	[thread overview]
Message-ID: <20210526134910.1c06c5d8@carbon> (raw)
In-Reply-To: <60add3cad4ef0_3b75f2086@john-XPS-13-9370.notmuch>

On Tue, 25 May 2021 21:51:22 -0700
John Fastabend <john.fastabend@gmail.com> 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


  reply	other threads:[~2021-05-26 11:51 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <dc2c38cdccfa5eca925cfc9d59b0674e208c9c9d.camel@intel.com>
     [not found] ` <2226aeaab7a4ca8e4f26413514bf54ab2c81ea36.camel@intel.com>
     [not found] ` <DM6PR11MB2780A8C5410ECB3C9700EAB5CA579@DM6PR11MB2780.namprd11.prod.outlook.com>
     [not found]   ` <PH0PR11MB487034313697F395BB5BA3C5E4579@PH0PR11MB4870.namprd11.prod.outlook.com>
     [not found]     ` <DM4PR11MB5422733A87913EFF8904C17184579@DM4PR11MB5422.namprd11.prod.outlook.com>
     [not found]       ` <20210507131034.5a62ce56@carbon>
     [not found]         ` <DM4PR11MB5422FE9618B3692D48FCE4EA84549@DM4PR11MB5422.namprd11.prod.outlook.com>
     [not found]           ` <20210510185029.1ca6f872@carbon>
     [not found]             ` <DM4PR11MB54227C25DFD4E882CB03BD3884539@DM4PR11MB5422.namprd11.prod.outlook.com>
     [not found]               ` <20210512102546.5c098483@carbon>
     [not found]                 ` <DM4PR11MB542273C9D8BF63505DC6E21784519@DM4PR11MB5422.namprd11.prod.outlook.com>
     [not found]                   ` <7b347a985e590e2a422f837971b30bd83f9c7ac3.camel@nvidia.com>
     [not found]                     ` <DM4PR11MB5422762E82C0531B92BDF09A842B9@DM4PR11MB5422.namprd11.prod.outlook.com>
     [not found]                       ` <DM4PR11MB5422269F6113268172B9E26A842A9@DM4PR11MB5422.namprd11.prod.outlook.com>
     [not found]                         ` <DM4PR11MB54224769926B06EE76635A6484299@DM4PR11MB5422.namprd11.prod.outlook.com>
     [not found]                           ` <20210521153110.207cb231@carbon>
     [not found]                             ` <1426b c91c6c6ee3aaf3d85c4291a12968634e521.camel@kernel.org>
     [not found]                               ` <87lf85zmuw.fsf@toke.dk>
2021-05-25 14:20                                 ` AF_XDP metadata/hints Alexander Lobakin
2021-05-26  4:51                                   ` John Fastabend
2021-05-26 11:49                                     ` Jesper Dangaard Brouer [this message]
2021-05-26 13:06                                       ` Toke Høiland-Jørgensen
2021-05-26 15:35                                         ` John Fastabend
2021-05-26 15:41                                           ` John Fastabend
2021-05-26 15:54                                           ` Alexander Lobakin
2021-05-26 16:33                                             ` John Fastabend
2021-05-26 18:44                                               ` Jesper Dangaard Brouer
2021-05-26 16:41                                             ` Alexei Starovoitov
2021-05-26 17:01                                               ` John Fastabend
2021-05-26 17:38                                           ` Jesper Dangaard Brouer
2021-05-26 14:49                                   ` Jesper Dangaard Brouer
2021-06-05  0:32           ` Desouza, Ederson
2021-06-11 19:25             ` Alexander Lobakin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210526134910.1c06c5d8@carbon \
    --to=brouer@redhat.com \
    --cc=alexandr.lobakin@intel.com \
    --cc=boon.leong.ong@intel.com \
    --cc=bpf@vger.kernel.org \
    --cc=ederson.desouza@intel.com \
    --cc=jesse.brandeburg@intel.com \
    --cc=jessica.zhang@intel.com \
    --cc=jithu.joseph@intel.com \
    --cc=john.fastabend@gmail.com \
    --cc=kishen.maloor@intel.com \
    --cc=kurt@linutronix.de \
    --cc=lukasz.czapnik@intel.com \
    --cc=marcin.kubiak@intel.com \
    --cc=marta.a.plantykow@intel.com \
    --cc=michal.swiatkowski@intel.com \
    --cc=piotr.raczynski@intel.com \
    --cc=saeed@kernel.org \
    --cc=toke@redhat.com \
    --cc=vinicius.gomes@intel.com \
    --cc=yoong.siang.song@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).