All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Wei Hu (Xavier)" <xavier.huwei-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
To: Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	Lijun Ou <oulijun-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>,
	sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
	hal.rosenstock-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
	davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org,
	jeffrey.t.kirsher-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
	jiri-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org,
	ogerlitz-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	gongyangming-hv44wF8Li93QT0dZR+AlfA@public.gmane.org,
	xiaokun-hv44wF8Li93QT0dZR+AlfA@public.gmane.org,
	tangchaofei-hv44wF8Li93QT0dZR+AlfA@public.gmane.org,
	haifeng.wei-hv44wF8Li93QT0dZR+AlfA@public.gmane.org,
	yisen.zhuang-hv44wF8Li93QT0dZR+AlfA@public.gmane.org,
	yankejian-hv44wF8Li93QT0dZR+AlfA@public.gmane.org,
	charles.chenxin-hv44wF8Li93QT0dZR+AlfA@public.gmane.org,
	linuxarm-hv44wF8Li93QT0dZR+AlfA@public.gmane.org
Subject: Re: [RESEND PATCH v7 17/21] IB/hns: Add QP operations support
Date: Mon, 23 May 2016 11:30:57 +0800	[thread overview]
Message-ID: <57427971.6090300@huawei.com> (raw)
In-Reply-To: <bf001e31-982a-c51d-782e-81ee19f9de09-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

Hi, Doug Ledford
    In hns_roce_cmd_wait and hns_roce_cmd_poll, there are down&up 
seminal operations,
    So, there are not deadlock and conflict, right?

static int hns_roce_cmd_poll(struct hns_roce_dev *hr_dev, u64 in_param,
			     u64 *out_param, unsigned long in_modifier,
			     u8 op_modifier, u16 op, unsigned long timeout)
{
	struct device *dev = &hr_dev->pdev->dev;
	u8 __iomem *hcr = hr_dev->cmd.hcr;
	unsigned long end = 0;
	u32 status = 0;
	int ret;

	down(&hr_dev->cmd.poll_sem);

	..// <snip>

	up (&hr_dev->cmd.poll_sem);
	return ret;
}

static int hns_roce_cmd_wait(struct hns_roce_dev *hr_dev, u64 in_param,
			     u64 *out_param, unsigned long in_modifier,
			     u8 op_modifier, u16 op, unsigned long timeout)
{
	struct hns_roce_cmdq *cmd = &hr_dev->cmd;
	struct device *dev = &hr_dev->pdev->dev;
	struct hns_roce_cmd_context *context;
	int ret = 0;

	down(&cmd->event_sem);

	..// <snip>

	up (&cmd->event_sem);
	return ret;
}

int __hns_roce_cmd(struct hns_roce_dev *hr_dev, u64 in_param, u64 *out_param,
		   unsigned long in_modifier, u8 op_modifier, u16 op,
		   unsigned long timeout)
{
	if (hr_dev->cmd.use_events)
		return hns_roce_cmd_wait(hr_dev, in_param, out_param,
					 in_modifier, op_modifier, op, timeout);
	else
		return hns_roce_cmd_poll(hr_dev, in_param, out_param,
					 in_modifier, op_modifier, op, timeout);
}



     Thanks.

Regards
Wei Hu

On 2016/5/14 5:52, Doug Ledford wrote:
> On 05/09/2016 11:04 PM, Lijun Ou wrote:
>> +int __hns_roce_cmd(struct hns_roce_dev *hr_dev, u64 in_param, u64 *out_param,
>> +		   unsigned long in_modifier, u8 op_modifier, u16 op,
>> +		   unsigned long timeout);
>> +
>> +/* Invoke a command with no output parameter */
>> +static inline int hns_roce_cmd(struct hns_roce_dev *hr_dev, u64 in_param,
>> +			       unsigned long in_modifier, u8 op_modifier,
>> +			       u16 op, unsigned long timeout)
>> +{
>> +	return __hns_roce_cmd(hr_dev, in_param, NULL, in_modifier,
>> +			      op_modifier, op, timeout);
>> +}
>> +
>> +/* Invoke a command with an output mailbox */
>> +static inline int hns_roce_cmd_box(struct hns_roce_dev *hr_dev, u64 in_param,
>> +				   u64 out_param, unsigned long in_modifier,
>> +				   u8 op_modifier, u16 op,
>> +				   unsigned long timeout)
>> +{
>> +	return __hns_roce_cmd(hr_dev, in_param, &out_param, in_modifier,
>> +			      op_modifier, op, timeout);
>> +}
> This will make people scratch their head in the future.  You are using
> two commands to map to one command without there being any locking
> involved.  The typical convention for routine_1() -> __routine_1() is
> that the __ version requires that it be called while locked, and the
> version without a __ does the locking before calling it.  That way a
> used can always know if they aren't currently holding the appropriate
> lock, then they6 call routine_1() and if they are, they call
> __routine_1() to avoid a deadlock.  I would suggest changing the name of
> __hns_roce_cmd to hns_roce_cmd_box and completely remove the existing
> hns_roce_cmd_box inline, and then change the hns_roce_cmd() inline to
> directly call hns_roce_cmd_box() which will then select between
> event/poll command sends.
>


--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: "Wei Hu (Xavier)" <xavier.huwei@huawei.com>
To: Doug Ledford <dledford@redhat.com>, Lijun Ou <oulijun@huawei.com>,
	<sean.hefty@intel.com>, <hal.rosenstock@gmail.com>,
	<davem@davemloft.net>, <jeffrey.t.kirsher@intel.com>,
	<jiri@mellanox.com>, <ogerlitz@mellanox.com>
Cc: <linux-rdma@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<netdev@vger.kernel.org>, <gongyangming@huawei.com>,
	<xiaokun@huawei.com>, <tangchaofei@huawei.com>,
	<haifeng.wei@huawei.com>, <yisen.zhuang@huawei.com>,
	<yankejian@huawei.com>, <charles.chenxin@huawei.com>,
	<linuxarm@huawei.com>
Subject: Re: [RESEND PATCH v7 17/21] IB/hns: Add QP operations support
Date: Mon, 23 May 2016 11:30:57 +0800	[thread overview]
Message-ID: <57427971.6090300@huawei.com> (raw)
In-Reply-To: <bf001e31-982a-c51d-782e-81ee19f9de09@redhat.com>

Hi, Doug Ledford
    In hns_roce_cmd_wait and hns_roce_cmd_poll, there are down&up 
seminal operations,
    So, there are not deadlock and conflict, right?

static int hns_roce_cmd_poll(struct hns_roce_dev *hr_dev, u64 in_param,
			     u64 *out_param, unsigned long in_modifier,
			     u8 op_modifier, u16 op, unsigned long timeout)
{
	struct device *dev = &hr_dev->pdev->dev;
	u8 __iomem *hcr = hr_dev->cmd.hcr;
	unsigned long end = 0;
	u32 status = 0;
	int ret;

	down(&hr_dev->cmd.poll_sem);

	..// <snip>

	up (&hr_dev->cmd.poll_sem);
	return ret;
}

static int hns_roce_cmd_wait(struct hns_roce_dev *hr_dev, u64 in_param,
			     u64 *out_param, unsigned long in_modifier,
			     u8 op_modifier, u16 op, unsigned long timeout)
{
	struct hns_roce_cmdq *cmd = &hr_dev->cmd;
	struct device *dev = &hr_dev->pdev->dev;
	struct hns_roce_cmd_context *context;
	int ret = 0;

	down(&cmd->event_sem);

	..// <snip>

	up (&cmd->event_sem);
	return ret;
}

int __hns_roce_cmd(struct hns_roce_dev *hr_dev, u64 in_param, u64 *out_param,
		   unsigned long in_modifier, u8 op_modifier, u16 op,
		   unsigned long timeout)
{
	if (hr_dev->cmd.use_events)
		return hns_roce_cmd_wait(hr_dev, in_param, out_param,
					 in_modifier, op_modifier, op, timeout);
	else
		return hns_roce_cmd_poll(hr_dev, in_param, out_param,
					 in_modifier, op_modifier, op, timeout);
}



     Thanks.

Regards
Wei Hu

On 2016/5/14 5:52, Doug Ledford wrote:
> On 05/09/2016 11:04 PM, Lijun Ou wrote:
>> +int __hns_roce_cmd(struct hns_roce_dev *hr_dev, u64 in_param, u64 *out_param,
>> +		   unsigned long in_modifier, u8 op_modifier, u16 op,
>> +		   unsigned long timeout);
>> +
>> +/* Invoke a command with no output parameter */
>> +static inline int hns_roce_cmd(struct hns_roce_dev *hr_dev, u64 in_param,
>> +			       unsigned long in_modifier, u8 op_modifier,
>> +			       u16 op, unsigned long timeout)
>> +{
>> +	return __hns_roce_cmd(hr_dev, in_param, NULL, in_modifier,
>> +			      op_modifier, op, timeout);
>> +}
>> +
>> +/* Invoke a command with an output mailbox */
>> +static inline int hns_roce_cmd_box(struct hns_roce_dev *hr_dev, u64 in_param,
>> +				   u64 out_param, unsigned long in_modifier,
>> +				   u8 op_modifier, u16 op,
>> +				   unsigned long timeout)
>> +{
>> +	return __hns_roce_cmd(hr_dev, in_param, &out_param, in_modifier,
>> +			      op_modifier, op, timeout);
>> +}
> This will make people scratch their head in the future.  You are using
> two commands to map to one command without there being any locking
> involved.  The typical convention for routine_1() -> __routine_1() is
> that the __ version requires that it be called while locked, and the
> version without a __ does the locking before calling it.  That way a
> used can always know if they aren't currently holding the appropriate
> lock, then they6 call routine_1() and if they are, they call
> __routine_1() to avoid a deadlock.  I would suggest changing the name of
> __hns_roce_cmd to hns_roce_cmd_box and completely remove the existing
> hns_roce_cmd_box inline, and then change the hns_roce_cmd() inline to
> directly call hns_roce_cmd_box() which will then select between
> event/poll command sends.
>

WARNING: multiple messages have this Message-ID (diff)
From: "Wei Hu (Xavier)" <xavier.huwei-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
To: Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	Lijun Ou <oulijun-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>,
	<sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
	<hal.rosenstock-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	<davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>,
	<jeffrey.t.kirsher-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
	<jiri-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>,
	<ogerlitz-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Cc: <linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	<netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	<gongyangming-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>,
	<xiaokun-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>,
	<tangchaofei-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>,
	<haifeng.wei-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>,
	<yisen.zhuang-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>,
	<yankejian-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>,
	<charles.chenxin-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>,
	<linuxarm-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
Subject: Re: [RESEND PATCH v7 17/21] IB/hns: Add QP operations support
Date: Mon, 23 May 2016 11:30:57 +0800	[thread overview]
Message-ID: <57427971.6090300@huawei.com> (raw)
In-Reply-To: <bf001e31-982a-c51d-782e-81ee19f9de09-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

Hi, Doug Ledford
    In hns_roce_cmd_wait and hns_roce_cmd_poll, there are down&up 
seminal operations,
    So, there are not deadlock and conflict, right?

static int hns_roce_cmd_poll(struct hns_roce_dev *hr_dev, u64 in_param,
			     u64 *out_param, unsigned long in_modifier,
			     u8 op_modifier, u16 op, unsigned long timeout)
{
	struct device *dev = &hr_dev->pdev->dev;
	u8 __iomem *hcr = hr_dev->cmd.hcr;
	unsigned long end = 0;
	u32 status = 0;
	int ret;

	down(&hr_dev->cmd.poll_sem);

	..// <snip>

	up (&hr_dev->cmd.poll_sem);
	return ret;
}

static int hns_roce_cmd_wait(struct hns_roce_dev *hr_dev, u64 in_param,
			     u64 *out_param, unsigned long in_modifier,
			     u8 op_modifier, u16 op, unsigned long timeout)
{
	struct hns_roce_cmdq *cmd = &hr_dev->cmd;
	struct device *dev = &hr_dev->pdev->dev;
	struct hns_roce_cmd_context *context;
	int ret = 0;

	down(&cmd->event_sem);

	..// <snip>

	up (&cmd->event_sem);
	return ret;
}

int __hns_roce_cmd(struct hns_roce_dev *hr_dev, u64 in_param, u64 *out_param,
		   unsigned long in_modifier, u8 op_modifier, u16 op,
		   unsigned long timeout)
{
	if (hr_dev->cmd.use_events)
		return hns_roce_cmd_wait(hr_dev, in_param, out_param,
					 in_modifier, op_modifier, op, timeout);
	else
		return hns_roce_cmd_poll(hr_dev, in_param, out_param,
					 in_modifier, op_modifier, op, timeout);
}



     Thanks.

Regards
Wei Hu

On 2016/5/14 5:52, Doug Ledford wrote:
> On 05/09/2016 11:04 PM, Lijun Ou wrote:
>> +int __hns_roce_cmd(struct hns_roce_dev *hr_dev, u64 in_param, u64 *out_param,
>> +		   unsigned long in_modifier, u8 op_modifier, u16 op,
>> +		   unsigned long timeout);
>> +
>> +/* Invoke a command with no output parameter */
>> +static inline int hns_roce_cmd(struct hns_roce_dev *hr_dev, u64 in_param,
>> +			       unsigned long in_modifier, u8 op_modifier,
>> +			       u16 op, unsigned long timeout)
>> +{
>> +	return __hns_roce_cmd(hr_dev, in_param, NULL, in_modifier,
>> +			      op_modifier, op, timeout);
>> +}
>> +
>> +/* Invoke a command with an output mailbox */
>> +static inline int hns_roce_cmd_box(struct hns_roce_dev *hr_dev, u64 in_param,
>> +				   u64 out_param, unsigned long in_modifier,
>> +				   u8 op_modifier, u16 op,
>> +				   unsigned long timeout)
>> +{
>> +	return __hns_roce_cmd(hr_dev, in_param, &out_param, in_modifier,
>> +			      op_modifier, op, timeout);
>> +}
> This will make people scratch their head in the future.  You are using
> two commands to map to one command without there being any locking
> involved.  The typical convention for routine_1() -> __routine_1() is
> that the __ version requires that it be called while locked, and the
> version without a __ does the locking before calling it.  That way a
> used can always know if they aren't currently holding the appropriate
> lock, then they6 call routine_1() and if they are, they call
> __routine_1() to avoid a deadlock.  I would suggest changing the name of
> __hns_roce_cmd to hns_roce_cmd_box and completely remove the existing
> hns_roce_cmd_box inline, and then change the hns_roce_cmd() inline to
> directly call hns_roce_cmd_box() which will then select between
> event/poll command sends.
>


--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  parent reply	other threads:[~2016-05-23  3:30 UTC|newest]

Thread overview: 66+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-10  3:04 [RESEND PATCH v7 00/21] Add HiSilicon RoCE driver Lijun Ou
2016-05-10  3:04 ` Lijun Ou
2016-05-10  3:04 ` Lijun Ou
2016-05-10  3:04 ` [RESEND PATCH v7 01/21] net: hns: Add reset function support for " Lijun Ou
2016-05-10  3:04   ` Lijun Ou
2016-05-10  3:04 ` [RESEND PATCH v7 02/21] devicetree: bindings: IB: Add binding document for HiSilicon RoCE Lijun Ou
2016-05-10  3:04   ` Lijun Ou
2016-05-10  3:04 ` [RESEND PATCH v7 03/21] IB/hns: Add initial main frame driver and get cfg info Lijun Ou
2016-05-10  3:04   ` Lijun Ou
2016-05-10  3:04 ` [RESEND PATCH v7 04/21] IB/hns: Add RoCE engine reset function Lijun Ou
2016-05-10  3:04   ` Lijun Ou
2016-05-10  3:04 ` [RESEND PATCH v7 06/21] IB/hns: Add initial cmd operation Lijun Ou
2016-05-10  3:04   ` Lijun Ou
2016-05-10  3:04 ` [RESEND PATCH v7 07/21] IB/hns: Add event queue support Lijun Ou
2016-05-10  3:04   ` Lijun Ou
     [not found]   ` <1462849483-67927-8-git-send-email-oulijun-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
2016-05-13 21:21     ` Doug Ledford
2016-05-13 21:21       ` Doug Ledford
2016-05-10  3:04 ` [RESEND PATCH v7 09/21] IB/hns: Add hca support Lijun Ou
2016-05-10  3:04   ` Lijun Ou
2016-05-10  3:04 ` [RESEND PATCH v7 10/21] IB/hns: Add process flow to init RoCE engine Lijun Ou
2016-05-10  3:04   ` Lijun Ou
2016-05-10  3:04 ` [RESEND PATCH v7 11/21] IB/hns: Add IB device registration Lijun Ou
2016-05-10  3:04   ` Lijun Ou
2016-05-10  3:04 ` [RESEND PATCH v7 12/21] IB/hns: Set mtu and gid support Lijun Ou
2016-05-10  3:04   ` Lijun Ou
     [not found] ` <1462849483-67927-1-git-send-email-oulijun-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
2016-05-10  3:04   ` [RESEND PATCH v7 05/21] IB/hns: Add initial profile resource Lijun Ou
2016-05-10  3:04     ` Lijun Ou
2016-05-10  3:04     ` Lijun Ou
2016-05-10  3:04   ` [RESEND PATCH v7 08/21] IB/hns: Add icm support Lijun Ou
2016-05-10  3:04     ` Lijun Ou
2016-05-10  3:04     ` Lijun Ou
2016-05-10  3:04   ` [RESEND PATCH v7 13/21] IB/hns: Add interface of the protocol stack registration Lijun Ou
2016-05-10  3:04     ` Lijun Ou
2016-05-10  3:04     ` Lijun Ou
2016-05-10  3:04   ` [RESEND PATCH v7 14/21] IB/hns: Add operations support for IB device and port Lijun Ou
2016-05-10  3:04     ` Lijun Ou
2016-05-10  3:04     ` Lijun Ou
2016-05-10  3:04   ` [RESEND PATCH v7 16/21] IB/hns: Add ah operations support Lijun Ou
2016-05-10  3:04     ` Lijun Ou
2016-05-10  3:04     ` Lijun Ou
2016-05-10  3:04   ` [RESEND PATCH v7 17/21] IB/hns: Add QP " Lijun Ou
2016-05-10  3:04     ` Lijun Ou
2016-05-10  3:04     ` Lijun Ou
     [not found]     ` <1462849483-67927-18-git-send-email-oulijun-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
2016-05-13 21:52       ` Doug Ledford
2016-05-13 21:52         ` Doug Ledford
     [not found]         ` <bf001e31-982a-c51d-782e-81ee19f9de09-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2016-05-23  3:30           ` Wei Hu (Xavier) [this message]
2016-05-23  3:30             ` Wei Hu (Xavier)
2016-05-23  3:30             ` Wei Hu (Xavier)
2016-05-13 22:04       ` Doug Ledford
2016-05-13 22:04         ` Doug Ledford
2016-05-13 21:09   ` [RESEND PATCH v7 00/21] Add HiSilicon RoCE driver Doug Ledford
2016-05-13 21:09     ` Doug Ledford
     [not found]     ` <ee4fe6df-e9b0-28da-c960-c288d6617025-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2016-05-23  1:06       ` Wei Hu (Xavier)
2016-05-23  1:06         ` Wei Hu (Xavier)
2016-05-23  1:06         ` Wei Hu (Xavier)
2016-05-10  3:04 ` [RESEND PATCH v7 15/21] IB/hns: Add PD operations support Lijun Ou
2016-05-10  3:04   ` Lijun Ou
2016-05-10  3:04 ` [RESEND PATCH v7 18/21] IB/hns: Add CQ " Lijun Ou
2016-05-10  3:04   ` Lijun Ou
2016-05-10  3:04 ` [RESEND PATCH v7 19/21] IB/hns: Add memory region " Lijun Ou
2016-05-10  3:04   ` Lijun Ou
2016-05-10  3:04 ` [RESEND PATCH v7 20/21] IB/hns: Kconfig and Makefile for RoCE module Lijun Ou
2016-05-10  3:04   ` Lijun Ou
2016-05-10  3:04 ` [RESEND PATCH v7 21/21] MAINTAINERS: Add maintainers for HiSilicon RoCE driver Lijun Ou
2016-05-10  3:04   ` Lijun Ou
     [not found] ` <5735B5D9.2030903@huawei.com>
     [not found]   ` <5735B5D9.2030903-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
2016-05-13 19:32     ` consult//Fwd: [RESEND PATCH v7 00/21] Add " Leon Romanovsky

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=57427971.6090300@huawei.com \
    --to=xavier.huwei-hv44wf8li93qt0dzr+alfa@public.gmane.org \
    --cc=charles.chenxin-hv44wF8Li93QT0dZR+AlfA@public.gmane.org \
    --cc=davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org \
    --cc=dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=gongyangming-hv44wF8Li93QT0dZR+AlfA@public.gmane.org \
    --cc=haifeng.wei-hv44wF8Li93QT0dZR+AlfA@public.gmane.org \
    --cc=hal.rosenstock-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=jeffrey.t.kirsher-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
    --cc=jiri-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linuxarm-hv44wF8Li93QT0dZR+AlfA@public.gmane.org \
    --cc=netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=ogerlitz-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org \
    --cc=oulijun-hv44wF8Li93QT0dZR+AlfA@public.gmane.org \
    --cc=sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
    --cc=tangchaofei-hv44wF8Li93QT0dZR+AlfA@public.gmane.org \
    --cc=xiaokun-hv44wF8Li93QT0dZR+AlfA@public.gmane.org \
    --cc=yankejian-hv44wF8Li93QT0dZR+AlfA@public.gmane.org \
    --cc=yisen.zhuang-hv44wF8Li93QT0dZR+AlfA@public.gmane.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 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.