All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: "shenjian (K)" <shenjian15@huawei.com>
Cc: Huazhong Tan <tanhuazhong@huawei.com>,
	Alexander Duyck <alexander.duyck@gmail.com>,
	<davem@davemloft.net>, <netdev@vger.kernel.org>,
	<salil.mehta@huawei.com>, <yisen.zhuang@huawei.com>,
	<huangdaode@huawei.com>, <linuxarm@openeuler.org>,
	<linuxarm@huawei.com>
Subject: Re: [PATCH net-next 8/9] net: hns3: add support for queue bonding mode of flow director
Date: Fri, 18 Jun 2021 15:01:56 -0700	[thread overview]
Message-ID: <20210618150156.0ffc88a0@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> (raw)
In-Reply-To: <9107b490-d74c-7ff2-de40-eb77770f0a64@huawei.com>

On Fri, 18 Jun 2021 09:18:21 +0800 shenjian (K) wrote:
> Hi  Jakub,
> 
> 
> 在 2021/3/18 9:28, Jakub Kicinski 写道:
> > On Thu, 18 Mar 2021 09:02:54 +0800 Huazhong Tan wrote:  
> >> On 2021/3/16 4:04, Jakub Kicinski wrote:  
> >>> On Mon, 15 Mar 2021 20:23:50 +0800 Huazhong Tan wrote:  
> >>>> From: Jian Shen <shenjian15@huawei.com>
> >>>>
> >>>> For device version V3, it supports queue bonding, which can
> >>>> identify the tuple information of TCP stream, and create flow
> >>>> director rules automatically, in order to keep the tx and rx
> >>>> packets are in the same queue pair. The driver set FD_ADD
> >>>> field of TX BD for TCP SYN packet, and set FD_DEL filed for
> >>>> TCP FIN or RST packet. The hardware create or remove a fd rule
> >>>> according to the TX BD, and it also support to age-out a rule
> >>>> if not hit for a long time.
> >>>>
> >>>> The queue bonding mode is default to be disabled, and can be
> >>>> enabled/disabled with ethtool priv-flags command.  
> >>> This seems like fairly well defined behavior, IMHO we should have a full
> >>> device feature for it, rather than a private flag.  
> >> Should we add a NETIF_F_NTUPLE_HW feature for it?  
> > It'd be better to keep the configuration close to the existing RFS
> > config, no? Perhaps a new file under
> >
> >    /sys/class/net/$dev/queues/rx-$id/
> >
> > to enable the feature would be more appropriate?
> >
> > Otherwise I'd call it something like NETIF_F_RFS_AUTO ?  
> I noticed that the enum NETIF_F_XXX_BIT has already used 64 bits since
> 
> NETIF_F_HW_HSR_DUP_BIT being added, while the prototype of 
> netdev_features_t
> 
> is u64.   So there is no useable bit for new feature if I understand 
> correct.
> 
> Is there any solution or plan for it ?

I think you'll need to start a new word.

  reply	other threads:[~2021-06-18 22:02 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-15 12:23 [PATCH net-next 0/9] net: hns3: refactor and new features for flow director Huazhong Tan
2021-03-15 12:23 ` [PATCH net-next 1/9] net: hns3: refactor out hclge_add_fd_entry() Huazhong Tan
2021-03-15 12:23 ` [PATCH net-next 2/9] net: hns3: refactor out hclge_fd_get_tuple() Huazhong Tan
2021-03-15 12:23 ` [PATCH net-next 3/9] net: hns3: refactor for function hclge_fd_convert_tuple Huazhong Tan
2021-03-15 12:23 ` [PATCH net-next 4/9] net: hns3: add support for traffic class tuple support for flow director by ethtool Huazhong Tan
2021-03-15 12:23 ` [PATCH net-next 5/9] net: hns3: refactor flow director configuration Huazhong Tan
2021-03-15 20:00   ` Jakub Kicinski
2021-03-17  1:47     ` Huazhong Tan
2021-03-17 18:32       ` Jakub Kicinski
2021-03-15 12:23 ` [PATCH net-next 6/9] net: hns3: refine for hns3_del_all_fd_entries() Huazhong Tan
2021-03-15 12:23 ` [PATCH net-next 7/9] net: hns3: add support for user-def data of flow director Huazhong Tan
2021-03-15 12:23 ` [PATCH net-next 8/9] net: hns3: add support for queue bonding mode " Huazhong Tan
2021-03-15 20:04   ` Jakub Kicinski
2021-03-18  1:02     ` Huazhong Tan
2021-03-18  1:28       ` Jakub Kicinski
2021-03-18  3:30         ` Alexander Duyck
2021-06-18  1:18         ` shenjian (K)
2021-06-18 22:01           ` Jakub Kicinski [this message]
2021-06-19  3:20             ` shenjian (K)
2021-03-15 12:23 ` [PATCH net-next 9/9] net: hns3: add queue bonding mode support for VF Huazhong Tan

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=20210618150156.0ffc88a0@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com \
    --to=kuba@kernel.org \
    --cc=alexander.duyck@gmail.com \
    --cc=davem@davemloft.net \
    --cc=huangdaode@huawei.com \
    --cc=linuxarm@huawei.com \
    --cc=linuxarm@openeuler.org \
    --cc=netdev@vger.kernel.org \
    --cc=salil.mehta@huawei.com \
    --cc=shenjian15@huawei.com \
    --cc=tanhuazhong@huawei.com \
    --cc=yisen.zhuang@huawei.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.