lkml.org 
[lkml]   [2021]   [Jan]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [RFC PATCH 0/7] Support for virtio-net hash reporting
    On Tue, Jan 12, 2021 at 9:41 PM Yuri Benditovich
    <yuri.benditovich@daynix.com> wrote:
    >
    > Existing TUN module is able to use provided "steering eBPF" to
    > calculate per-packet hash and derive the destination queue to
    > place the packet to. The eBPF uses mapped configuration data
    > containing a key for hash calculation and indirection table
    > with array of queues' indices.
    >
    > This series of patches adds support for virtio-net hash reporting
    > feature as defined in virtio specification. It extends the TUN module
    > and the "steering eBPF" as follows:
    >
    > Extended steering eBPF calculates the hash value and hash type, keeps
    > hash value in the skb->hash and returns index of destination virtqueue
    > and the type of the hash. TUN module keeps returned hash type in
    > (currently unused) field of the skb.
    > skb->__unused renamed to 'hash_report_type'.
    >
    > When TUN module is called later to allocate and fill the virtio-net
    > header and push it to destination virtqueue it populates the hash
    > and the hash type into virtio-net header.
    >
    > VHOST driver is made aware of respective virtio-net feature that
    > extends the virtio-net header to report the hash value and hash report
    > type.

    Comment from Willem de Bruijn:

    Skbuff fields are in short supply. I don't think we need to add one
    just for this narrow path entirely internal to the tun device.

    Instead, you could just run the flow_dissector in tun_put_user if the
    feature is negotiated. Indeed, the flow dissector seems more apt to me
    than BPF here. Note that the flow dissector internally can be
    overridden by a BPF program if the admin so chooses.

    This also hits on a deeper point with the choice of hash values, that
    I also noticed in my RFC patchset to implement the inverse [1][2]. It
    is much more detailed than skb->hash + skb->l4_hash currently offers,
    and that can be gotten for free from most hardware. In most practical
    cases, that information suffices. I added less specific fields
    VIRTIO_NET_HASH_REPORT_L4, VIRTIO_NET_HASH_REPORT_OTHER that work
    without explicit flow dissection. I understand that the existing
    fields are part of the standard. Just curious, what is their purpose
    beyond 4-tuple based flow hashing?

    [1] https://patchwork.kernel.org/project/netdevbpf/list/?series=406859&state=*
    [2] https://github.com/wdebruij/linux/commit/0f77febf22cd6ffc242a575807fa8382a26e511e
    >
    > Yuri Benditovich (7):
    > skbuff: define field for hash report type
    > vhost: support for hash report virtio-net feature
    > tun: allow use of BPF_PROG_TYPE_SCHED_CLS program type
    > tun: free bpf_program by bpf_prog_put instead of bpf_prog_destroy
    > tun: add ioctl code TUNSETHASHPOPULATION
    > tun: populate hash in virtio-net header when needed
    > tun: report new tun feature IFF_HASH
    >
    > drivers/net/tun.c | 43 +++++++++++++++++++++++++++++++------
    > drivers/vhost/net.c | 37 ++++++++++++++++++++++++-------
    > include/linux/skbuff.h | 7 +++++-
    > include/uapi/linux/if_tun.h | 2 ++
    > 4 files changed, 74 insertions(+), 15 deletions(-)
    >
    > --
    > 2.17.1
    >

    \
     
     \ /
      Last update: 2021-01-12 20:51    [W:3.481 / U:0.012 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site