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=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no 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 588AAC74A21 for ; Wed, 10 Jul 2019 15:37:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 34CA42064A for ; Wed, 10 Jul 2019 15:37:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727620AbfGJPhN (ORCPT ); Wed, 10 Jul 2019 11:37:13 -0400 Received: from mail-wr1-f47.google.com ([209.85.221.47]:36168 "EHLO mail-wr1-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726105AbfGJPhM (ORCPT ); Wed, 10 Jul 2019 11:37:12 -0400 Received: by mail-wr1-f47.google.com with SMTP id n4so2984110wrs.3 for ; Wed, 10 Jul 2019 08:37:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition:user-agent; bh=w6gOM0EF8w6OgRkN0S1HwMV2ZTxvl6sDwbz7UvtM7Ds=; b=JiOXQ/rctKhfa2fGHHzHGDKiDaWos3kjLiWPulrHNcXoIjan+KHESQ/264wzDlB92O p06DeAEovfE0z372C9QM7NbzoQKmZDKY7a61dpz2JeNFpCmupEilD3ewhjluDOS4w7c3 ZBVD35Qo+mzpUQ0uoJV1iPuFobSvFznXPVhGfn8ViUEw5o8oczRL0C7bFNn5XcAj45H0 yvm03BX8gpcON8CYumjrE3bAWnGbJEIJzSblAahk+G9a7/6I2QkpmvSR0wrfd19mpFKD 00zGSec0Es3blIavr/2iY+t5o1xikA+coI2u+D2hRRDKz2QTF8+kMJcZxXVoa7e9Hhwa GwgA== X-Gm-Message-State: APjAAAUFCIuaKJAp86NwdoL1DB5E/gSmASTAnsAK9/Q1z4ky390eF7Du bt9rwuWK4C+TURLdHj1Cxe2y3g== X-Google-Smtp-Source: APXvYqw5KGnsPShaRheRWeLkyw7iNHfzH6H8mZGknsxq9TfA80oFKuQNpokcGJJXQu9Hu6et/y/htg== X-Received: by 2002:a5d:468a:: with SMTP id u10mr32491868wrq.177.1562773029910; Wed, 10 Jul 2019 08:37:09 -0700 (PDT) Received: from steredhat (host122-201-dynamic.13-79-r.retail.telecomitalia.it. [79.13.201.122]) by smtp.gmail.com with ESMTPSA id 15sm1847474wmk.34.2019.07.10.08.37.09 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Wed, 10 Jul 2019 08:37:09 -0700 (PDT) Date: Wed, 10 Jul 2019 17:37:07 +0200 From: Stefano Garzarella To: "Michael S. Tsirkin" , Jason Wang , Stefan Hajnoczi Cc: virtualization@lists.linux-foundation.org, netdev@vger.kernel.org Subject: [RFC] virtio-net: share receive_*() and add_recvbuf_*() with virtio-vsock Message-ID: <20190710153707.twmzgmwqqw3pstos@steredhat> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: NeoMutt/20180716 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Hi, as Jason suggested some months ago, I looked better at the virtio-net driver to understand if we can reuse some parts also in the virtio-vsock driver, since we have similar challenges (mergeable buffers, page allocation, small packets, etc.). Initially, I would add the skbuff in the virtio-vsock in order to re-use receive_*() functions. Then I would move receive_[small, big, mergeable]() and add_recvbuf_[small, big, mergeable]() outside of virtio-net driver, in order to call them also from virtio-vsock. I need to do some refactoring (e.g. leave the XDP part on the virtio-net driver), but I think it is feasible. The idea is to create a virtio-skb.[h,c] where put these functions and a new object where stores some attributes needed (e.g. hdr_len ) and status (e.g. some fields of struct receive_queue). This is an idea of virtio-skb.h that I have in mind: struct virtskb; struct sk_buff *virtskb_receive_small(struct virtskb *vs, ...); struct sk_buff *virtskb_receive_big(struct virtskb *vs, ...); struct sk_buff *virtskb_receive_mergeable(struct virtskb *vs, ...); int virtskb_add_recvbuf_small(struct virtskb*vs, ...); int virtskb_add_recvbuf_big(struct virtskb *vs, ...); int virtskb_add_recvbuf_mergeable(struct virtskb *vs, ...); For the Guest->Host path it should be easier, so maybe I can add a "virtskb_send(struct virtskb *vs, struct sk_buff *skb)" with a part of the code of xmit_skb(). Let me know if you have in mind better names or if I should put these function in another place. I would like to leave the control part completely separate, so, for example, the two drivers will negotiate the features independently and they will call the right virtskb_receive_*() function based on the negotiation. I already started to work on it, but before to do more steps and send an RFC patch, I would like to hear your opinion. Do you think that makes sense? Do you see any issue or a better solution? Thanks in advance, Stefano