From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
To: Jakub Kicinski <kubakici@wp.pl>
Cc: Jesper Dangaard Brouer <brouer@redhat.com>,
Daniel Borkmann <borkmann@iogearbox.net>,
John Fastabend <john.r.fastabend@intel.com>,
netdev@vger.kernel.org
Subject: Re: [RFC net-next PATCH 4/5] net: new XDP feature for reading HW rxhash from drivers
Date: Fri, 19 May 2017 20:34:00 -0700 [thread overview]
Message-ID: <20170520033358.hjz7ocy2fupwplym@ast-mbp> (raw)
In-Reply-To: <20170519202147.3c6bda7f@cakuba.netronome.com>
On Fri, May 19, 2017 at 08:21:47PM -0700, Jakub Kicinski wrote:
> On Fri, 19 May 2017 20:07:52 -0700, Alexei Starovoitov wrote:
> > How about exposing 'struct mlx5_cqe64 *' to XDP programs as-is?
> > We can make sure that XDP program does read only access into it and
> > it will see cqe->rss_hash_result, cqe->rss_hash_type and everything else
> > in there, but this will not be uapi and it will be pretty obvious
> > to program authors that their programs are vendor specific.
> > 'not uapi' here means that mellanox is free to change their HW descriptor
> > and its contents as they wish.
>
> Hm.. Would that mean we have to teach the verifier about all possible
> drivers and their metadata structures (i.e. sizes thereof). And add an
> UAPI enum of known drivers?
why? no uapi other than a pointer to this hw rx descriptor.
Different sizeof(hw_rx_descriptor) is not a problem.
We deal with it already in tracing. All tracepoints have different
sizeof(*ctx), yet the safety is preserved.
> Other idea I floated in early days was to standardize the fields but
> let the driver "JIT" the accesses to look at the right offset of the
> right structure. Admittedly that would be a lot more work.
'standardize the fields' sounds nice, but failed here already.
As far as I can see the meaning of packet 'hash' is quite different
across the drivers and 'hash' is just a beginning.
I hope we can standardize on 'csum' field and make it checksum_complete,
but so far out of 10+G nics only mlx5 and nfp do it in hw.
We need it at least for mlx4, but it can only fake it via expensive math.
next prev parent reply other threads:[~2017-05-20 3:34 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-18 15:41 [RFC net-next PATCH 0/5] XDP driver feature API and handling change to xdp_buff Jesper Dangaard Brouer
2017-05-18 15:41 ` [RFC net-next PATCH 1/5] samples/bpf: xdp_tx_iptunnel make use of map_data[] Jesper Dangaard Brouer
2017-05-19 15:45 ` Daniel Borkmann
2017-05-18 15:41 ` [RFC net-next PATCH 2/5] mlx5: fix bug reading rss_hash_type from CQE Jesper Dangaard Brouer
2017-05-19 15:47 ` Daniel Borkmann
2017-05-19 23:38 ` David Miller
2017-05-22 18:27 ` Jesper Dangaard Brouer
2017-05-18 15:41 ` [RFC net-next PATCH 3/5] net: introduce XDP driver features interface Jesper Dangaard Brouer
2017-05-19 17:13 ` Daniel Borkmann
2017-05-19 23:37 ` David Miller
2017-05-20 7:53 ` Jesper Dangaard Brouer
2017-05-21 0:58 ` Daniel Borkmann
2017-05-22 14:49 ` Jesper Dangaard Brouer
2017-05-22 17:07 ` Daniel Borkmann
2017-05-30 9:58 ` Jesper Dangaard Brouer
2017-05-18 15:41 ` [RFC net-next PATCH 4/5] net: new XDP feature for reading HW rxhash from drivers Jesper Dangaard Brouer
2017-05-19 11:47 ` Jesper Dangaard Brouer
2017-05-20 3:07 ` Alexei Starovoitov
2017-05-20 3:21 ` Jakub Kicinski
2017-05-20 3:34 ` Alexei Starovoitov [this message]
2017-05-20 4:13 ` Jakub Kicinski
2017-05-21 15:55 ` Jesper Dangaard Brouer
2017-05-22 3:21 ` Alexei Starovoitov
2017-05-22 4:12 ` John Fastabend
2017-05-20 16:16 ` Tom Herbert
2017-05-21 16:04 ` Jesper Dangaard Brouer
2017-05-21 22:10 ` Tom Herbert
2017-05-22 6:39 ` Jesper Dangaard Brouer
2017-05-22 20:42 ` Jesper Dangaard Brouer
2017-05-22 21:32 ` Tom Herbert
2017-05-18 15:41 ` [RFC net-next PATCH 5/5] mlx5: add XDP rxhash feature for driver mlx5 Jesper Dangaard Brouer
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=20170520033358.hjz7ocy2fupwplym@ast-mbp \
--to=alexei.starovoitov@gmail.com \
--cc=borkmann@iogearbox.net \
--cc=brouer@redhat.com \
--cc=john.r.fastabend@intel.com \
--cc=kubakici@wp.pl \
--cc=netdev@vger.kernel.org \
/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