old -->| payload |
We can use a buffer plus a separate page when allocating the receive
buffer. In this way, we can ensure that all payloads can be
independently in a page, which is very beneficial for the zerocopy
implemented by the upper layer.
Signed-off-by: Xuan Zhuo
Signed-off-by: H
The content of the mail just sent is about "[PATCH v6] virtio_net:
support split header".
在 2022/8/1 下午2:59, Heng Qi 写道:
From: Xuan Zhuo
The purpose of this feature is to split the header and the payload of
the packet.
|rece
在 2022/8/4 下午2:27, Jason Wang 写道:
On Mon, Aug 1, 2022 at 2:59 PM Heng Qi wrote:
From: Xuan Zhuo
The purpose of this feature is to split the header and the payload of
the packet.
|receive buffer|
| 0th descriptor
在 2022/8/4 下午9:50, Cornelia Huck 写道:
On Thu, Aug 04 2022, Heng Qi wrote:
在 2022/8/4 下午2:27, Jason Wang 写道:
On Mon, Aug 1, 2022 at 2:59 PM Heng Qi wrote:
@@ -3820,9 +3826,13 @@ \subsubsection{Processing of Incoming
Packets}\label{sec:Device Types / Network
driver MUST NOT use the
在 2022/8/9 下午5:18, Jason Wang 写道:
On Thu, Aug 4, 2022 at 8:48 PM Heng Qi wrote:
在 2022/8/4 下午2:27, Jason Wang 写道:
On Mon, Aug 1, 2022 at 2:59 PM Heng Qi wrote:
From: Xuan Zhuo
The purpose of this feature is to split the header and the payload of
the packet.
|receive
old -->| payload |
We can use a buffer plus a separate page when allocating the receive
buffer. In this way, we can ensure that all payloads can be
independently in a page, which is very beneficial for the zerocopy
implemented by the upper layer.
Signed-off-by: Xuan Zhuo
Signed-off-by: H
在 2022/8/25 下午10:22, Cornelia Huck 写道:
On Tue, Aug 16 2022, Heng Qi wrote:
From: Xuan Zhuo
The purpose of this feature is to split the header and the payload of
the packet.
|receive buffer|
| 0th descriptor
在 2022/8/16 下午5:34, Heng Qi 写道:
From: Xuan Zhuo
The purpose of this feature is to split the header and the payload of
the packet.
|receive buffer|
| 0th descriptor | 1th descriptor|
| virtnet hdr
在 2022/8/16 下午5:34, Heng Qi 写道:
From: Xuan Zhuo
The purpose of this feature is to split the header and the payload of
the packet.
|receive buffer|
| 0th descriptor | 1th descriptor|
| virtnet hdr
在 2022/9/2 下午2:21, Jason Wang 写道:
On Tue, Aug 16, 2022 at 5:35 PM Heng Qi wrote:
From: Xuan Zhuo
The purpose of this feature is to split the header and the payload of
the packet.
|receive buffer|
| 0th descriptor
在 2022/9/2 下午2:21, Jason Wang 写道:
On Tue, Aug 16, 2022 at 5:35 PM Heng Qi wrote:
From: Xuan Zhuo
The purpose of this feature is to split the header and the payload of
the packet.
|receive buffer|
| 0th descriptor
在 2022/9/2 下午2:41, Michael S. Tsirkin 写道:
On Fri, Sep 02, 2022 at 02:21:04PM +0800, Jason Wang wrote:
On Tue, Aug 16, 2022 at 5:35 PM Heng Qi wrote:
From: Xuan Zhuo
The purpose of this feature is to split the header and the payload of
the packet.
|receive buffer
在 2022/9/5 下午3:52, Xuan Zhuo 写道:
On Sun, 4 Sep 2022 16:31:59 -0400, "Michael S. Tsirkin" wrote:
On Fri, Sep 02, 2022 at 04:58:16PM +0800, Heng Qi wrote:
When VIRTIO_NET_F_SPLIT_TRANSPORT_HEADER is negotiated,
the driver requires that the buffers submitted to receiveq
MUST be comp
在 2022/8/16 下午5:34, Heng Qi 写道:
From: Xuan Zhuo
The purpose of this feature is to split the header and the payload of
the packet.
|receive buffer|
| 0th descriptor | 1th descriptor|
| virtnet hdr
在 2022/9/5 上午4:27, Michael S. Tsirkin 写道:
On Fri, Sep 02, 2022 at 03:36:25PM +0800, Heng Qi wrote:
We need to clarify that the purpose of header splitting is to make all payloads
can be independently in a page, which is beneficial for the zerocopy
implemented by the upper layer.
absolutely
On Sun, Sep 04, 2022 at 04:27:38PM -0400, Michael S. Tsirkin wrote:
> On Fri, Sep 02, 2022 at 03:36:25PM +0800, Heng Qi wrote:
> > We need to clarify that the purpose of header splitting is to make all
> > payloads
> > can be independently in a page, which is benefi
On Fri, Sep 09, 2022 at 08:47:57PM +0800, Xuan Zhuo wrote:
>
> hi
>Qi also sent another same email today. Due to some email client problems,
>this email has some confusion in the format, so we can discuss
>under another one.
>
>https://lists.oasis-open.org/archives/virtio-dev/2022
在 2022/9/28 上午5:35, Michael S. Tsirkin 写道:
On Wed, Sep 14, 2022 at 11:34:43AM +0800, Jason Wang wrote:
在 2022/9/9 20:38, Xuan Zhuo 写道:
On Fri, 9 Sep 2022 07:15:02 -0400, "Michael S. Tsirkin" wrote:
On Fri, Sep 09, 2022 at 03:41:54PM +0800, Heng Qi wrote:
在 2022/9/5 上午4:27,
On Sat, Oct 08, 2022 at 12:37:45PM +0800, Jason Wang wrote:
> On Thu, Sep 29, 2022 at 3:04 PM Michael S. Tsirkin wrote:
> >
> > On Thu, Sep 29, 2022 at 09:48:33AM +0800, Jason Wang wrote:
> > > On Wed, Sep 28, 2022 at 9:39 PM Michael S. Tsirkin
> > > wrote:
> > > >
> > > > On Mon, Sep 26, 2022 a
rsion releases, so I sincerely request that you please review
it as soon as possible.
Thanks!
在 2023/12/12 下午5:30, Heng Qi 写道:
在 2023/12/12 下午5:23, Heng Qi 写道:
在 2023/12/12 下午4:44, Michael S. Tsirkin 写道:
On Tue, Dec 12, 2023 at 11:28:21AM +0800, Heng Qi wrote:
在 2023/12/12 上午12:35, Mich
在 2023/12/18 上午11:10, Jason Wang 写道:
On Fri, Dec 15, 2023 at 5:51 PM Heng Qi wrote:
Hi all!
I would like to ask if anyone has any comments on this version, if so
please let me know!
If not, I will collect Michael's comments and publish a new version next
Monday.
I have a dumb que
在 2023/12/19 下午3:53, Jason Wang 写道:
On Mon, Dec 18, 2023 at 12:54 PM Heng Qi wrote:
在 2023/12/18 上午11:10, Jason Wang 写道:
On Fri, Dec 15, 2023 at 5:51 PM Heng Qi wrote:
Hi all!
I would like to ask if anyone has any comments on this version, if so
please let me know!
If not, I will
在 2023/12/20 下午1:48, Jason Wang 写道:
On Wed, Dec 20, 2023 at 12:07 AM Heng Qi wrote:
在 2023/12/19 下午3:53, Jason Wang 写道:
On Mon, Dec 18, 2023 at 12:54 PM Heng Qi wrote:
在 2023/12/18 上午11:10, Jason Wang 写道:
On Fri, Dec 15, 2023 at 5:51 PM Heng Qi wrote:
Hi all!
I would like to ask
在 2023/12/20 下午2:59, Jason Wang 写道:
On Wed, Dec 20, 2023 at 2:30 PM Heng Qi wrote:
在 2023/12/20 下午1:48, Jason Wang 写道:
On Wed, Dec 20, 2023 at 12:07 AM Heng Qi wrote:
在 2023/12/19 下午3:53, Jason Wang 写道:
On Mon, Dec 18, 2023 at 12:54 PM Heng Qi wrote:
在 2023/12/18 上午11:10, Jason
在 2023/12/20 下午3:35, Michael S. Tsirkin 写道:
On Wed, Dec 20, 2023 at 02:30:01PM +0800, Heng Qi wrote:
But why are we discussing this?
I think basically at this point everyone is confused about what
the feature does. right now we have packets
with
#define VIRTIO_NET_HDR_F_NEEDS_CSUM 1
在 2023/12/20 下午2:59, Jason Wang 写道:
On Wed, Dec 20, 2023 at 2:30 PM Heng Qi wrote:
在 2023/12/20 下午1:48, Jason Wang 写道:
On Wed, Dec 20, 2023 at 12:07 AM Heng Qi wrote:
在 2023/12/19 下午3:53, Jason Wang 写道:
On Mon, Dec 18, 2023 at 12:54 PM Heng Qi wrote:
在 2023/12/18 上午11:10, Jason
在 2023/12/21 上午9:34, Jason Wang 写道:
On Wed, Dec 20, 2023 at 3:42 PM Heng Qi wrote:
在 2023/12/20 下午2:59, Jason Wang 写道:
On Wed, Dec 20, 2023 at 2:30 PM Heng Qi wrote:
在 2023/12/20 下午1:48, Jason Wang 写道:
On Wed, Dec 20, 2023 at 12:07 AM Heng Qi wrote:
在 2023/12/19 下午3:53, Jason Wang
在 2023/12/21 上午9:34, Jason Wang 写道:
On Wed, Dec 20, 2023 at 3:35 PM Michael S. Tsirkin wrote:
On Wed, Dec 20, 2023 at 02:30:01PM +0800, Heng Qi wrote:
But why are we discussing this?
I think basically at this point everyone is confused about what
the feature does. right now we have
在 2024/1/23 下午3:15, Michael S. Tsirkin 写道:
On Tue, Jan 23, 2024 at 05:55:02AM +, Parav Pandit wrote:
From: Michael S. Tsirkin
Sent: Monday, January 22, 2024 1:06 PM
On Mon, Jan 22, 2024 at 05:03:38AM +, Parav Pandit wrote:
The right test on Linux to do without rtnl lock which is an
在 2024/1/22 下午1:03, Parav Pandit 写道:
From: Heng Qi
Sent: Monday, January 22, 2024 8:27 AM
在 2024/1/20 下午5:59, Parav Pandit 写道:
From: Heng Qi
Sent: Wednesday, January 17, 2024 10:22 AM
在 2024/1/15 下午9:21, Parav Pandit 写道:
From: virtio-comm...@lists.oasis-open.org
On Behalf Of Heng Qi
在 2022/11/9 下午9:23, Michael S. Tsirkin 写道:
On Wed, Nov 09, 2022 at 07:35:14PM +0800, Heng Qi wrote:
Please ignore this email.
Thanks.
ok. if 2/2 is still relevant pls post it separately.
I sent a new patch set with a cover-letter, please see in
https://lists.oasis-open.org/archives
在 2022/12/16 下午8:49, Michael S. Tsirkin 写道:
On Mon, Dec 05, 2022 at 02:36:39PM +0800, Heng Qi wrote:
@@ -4005,6 +4159,24 @@ \subsubsection{Processing of Incoming
Packets}\label{sec:Device Types / Network
#define VIRTIO_NET_HASH_REPORT_UDPv6_EX9
\end{lstlisting}
+If \field
在 2022/12/21 下午7:48, Alvaro Karsz 写道:
Hi,
I want to know which one is better than NetDim(Coalesce Adaptive) in driver.
I know Heng Qi's work in this.
Thanks
Why choose? we can have both.
ethtool can handle both pkt_rate_low/pkt_rate_high and
use_adaptive_rx_coalesce/use_adaptive_tx_coale
On Tue, Jan 10, 2023 at 12:57:38AM -0500, Michael S. Tsirkin wrote:
> On Tue, Jan 10, 2023 at 12:25:02AM -0500, Michael S. Tsirkin wrote:
> > > This will give extra pressure on the management stack, e.g it requires
> > > the device to have an out of spec way for introspection.
> > >
> > > Thanks
>
在 2023/1/9 下午7:39, Michael S. Tsirkin 写道:
Btw this "are defined below" all over the place is just contributing
to making the spec unnecesarily verbose. Simple "are:" will do.
Sure. I'll fix it in the next version.
Thanks.
---
在 2023/1/10 下午3:26, Heng Qi 写道:
On Tue, Jan 10, 2023 at 12:57:38AM -0500, Michael S. Tsirkin wrote:
On Tue, Jan 10, 2023 at 12:25:02AM -0500, Michael S. Tsirkin wrote:
This will give extra pressure on the management stack, e.g it requires
the device to have an out of spec way for
On Wed, Jan 18, 2023 at 11:45:39PM +, Parav Pandit wrote:
>
>
> > From: virtio-dev@lists.oasis-open.org
> > Sent: Wednesday, January 4, 2023 2:14 AM
>
> > If the tunnel is used to encapsulate the packets, the hash calculated using
> > the
> > outer header of the receive packets is always
在 2023/2/2 上午11:55, Parav Pandit 写道:
From: virtio-comm...@lists.oasis-open.org On Behalf Of Michael S. Tsirkin
Sent: Wednesday, February 1, 2023 1:57 AM
Also, this patch is adding two functionalities.
1. Inner header hash calculation of existing already defined hash
types 2. outer header has
在 2023/2/7 上午5:53, Parav Pandit 写道:
From: virtio-dev@lists.oasis-open.org On
Behalf Of Michael S. Tsirkin
On Mon, Feb 06, 2023 at 07:13:43PM +, Parav Pandit wrote:
From: virtio-dev@lists.oasis-open.org
On Behalf Of Alvaro Karsz
This patch makes several improvements to the notifica
在 2023/2/8 下午6:10, Michael S. Tsirkin 写道:
On Wed, Feb 08, 2023 at 09:57:54AM +0800, Heng Qi wrote:
I think it's a good idea to do this on top of Alvaro's patch
unifying these two structures.
I saw Alvaro's patch, but it doesn't seem to be stable yet, is there a good
way
Parav Pandit wrote:
From: Michael S. Tsirkin
Sent: Wednesday, February 8, 2023 9:18 AM
On Wed, Feb 08, 2023 at 07:30:34PM +0800, Heng Qi wrote:
I see two options.
1. Just have per VQ params. Software has the full knowledge
of in which it is
operating, and state remains at software level.
在 2023/2/9 上午6:35, Alvaro Karsz 写道:
From: Alvaro Karsz
Sent: Wednesday, February 8, 2023 4:56 PM
Alvaro,
Do you know if any software used it? Can you get some real data?
I implemented this feature in our DPU, so at least 1 vendor is using this
feature
But which software (virtio net driver
nesday, February 8, 2023 9:43 AM
On Wed, Feb 08, 2023 at 02:37:55PM +, Parav Pandit wrote:
From: Michael S. Tsirkin
Sent: Wednesday, February 8, 2023 9:18 AM
On Wed, Feb 08, 2023 at 07:30:34PM +0800, Heng Qi wrote:
I see two options.
1. Just have per VQ params. Software has the full knowledge
of in
Pandit wrote:
From: Michael S. Tsirkin
Sent: Wednesday, February 8, 2023 9:18 AM
On Wed, Feb 08, 2023 at 07:30:34PM +0800, Heng Qi wrote:
I see two options.
1. Just have per VQ params. Software has the full knowledge
of in which it is
operating, and state remains at software level.
This effectively
在 2023/2/10 下午6:16, Alvaro Karsz 写道:
So, should we remove VIRTIO_NET_F_CTRL_VQ here, or fix VIRTIO_NET_F_HOST_ECN?
Ah good point.
But I think VIRTIO_NET_F_VQ_NOTF_COAL should not depend on
VIRTIO_NET_F_NOTF_COAL.
This way devices can drop the all-rx/all-tx commands if they want to.
We need
在 2023/2/11 下午4:45, Alvaro Karsz 写道:
Please add short description something like,
When the driver prefers to use per virtqueue notifications coalescing, and if
queue group (transmit or receive) level notification coalescing is enabled,
driver SHOULD first disable device level notification c
On Sat, Feb 11, 2023 at 01:47:16PM +, Parav Pandit wrote:
>
>
> > From: Alvaro Karsz
> > Sent: Saturday, February 11, 2023 3:45 AM
> >
> > > Please add short description something like,
> > >
> > > When the driver prefers to use per virtqueue notifications coalescing,
> > > and if
> > queu
On Sat, Feb 11, 2023 at 06:13:55PM +0200, Alvaro Karsz wrote:
> I think that I wasn't clear enough.
>
> I'm not saying that we should not define in the spec how to handle a
> situation when a device receives both RX_SET and VQ_SET (or a driver
> sends both).
> I'm saying that I don't think that t
On Sun, Feb 12, 2023 at 04:35:37AM -0500, Michael S. Tsirkin wrote:
> On Sat, Feb 11, 2023 at 01:47:16PM +, Parav Pandit wrote:
> >
> >
> > > From: Alvaro Karsz
> > > Sent: Saturday, February 11, 2023 3:45 AM
> > >
> > > > Please add short description something like,
> > > >
> > > > When th
在 2023/2/16 下午3:32, Alvaro Karsz 写道:
This patch makes several improvements to the notification coalescing
feature, including:
- Consolidating virtio_net_ctrl_coal_tx and virtio_net_ctrl_coal_rx
into a single struct, virtio_net_ctrl_coal, as they are identical.
- Emphasizing that the coales
On Fri, Feb 17, 2023 at 10:42:21AM +0200, Alvaro Karsz wrote:
> Hi Heng,
>
> > +\item[VIRTIO_NET_F_VQ_NOTF_COAL(52)] Device supports the virtqueue
> > +notifications coalescing.
> > +
> > \item[VIRTIO_NET_F_NOTF_COAL(53)] Device supports notifications coalescing.
> >
> > \item[VIRTIO_NET_F_G
On Fri, Feb 17, 2023 at 11:40:15AM +0200, Alvaro Karsz wrote:
> > > Maybe we can use struct virtio_net_ctrl_coal inside struct
> > > virtio_net_ctrl_coal_vq instead of repeating max_usecs and
> > > max_packets?
> > > I'm not sure if it would be confusing, what do you think?
> > >
> >
> > Hi Alvaro.
在 2023/2/18 上午12:24, Parav Pandit 写道:
From: virtio-dev@lists.oasis-open.org On
Behalf Of Heng Qi
[..]
We assume that hash_report_tunnel_types is still present in the next version,
I am little lost.
Hi, Parav.
You are not lost. I'm just answering some of Michael's questions a
在 2023/2/17 下午6:07, Michael S. Tsirkin 写道:
On Fri, Feb 17, 2023 at 11:40:15AM +0200, Alvaro Karsz wrote:
Maybe we can use struct virtio_net_ctrl_coal inside struct
virtio_net_ctrl_coal_vq instead of repeating max_usecs and
max_packets?
I'm not sure if it would be confusing, what do you think?
On Fri, Feb 17, 2023 at 04:12:34PM +, Parav Pandit wrote:
>
> > From: Michael S. Tsirkin
> > Sent: Friday, February 17, 2023 6:35 AM
>
> > > We mention the device reset case, but nothing about VQ reset.
> > >
> > > I feel that no matter how we handle this, we break something.
> > >
> > > Hav
Hi, Alvaro.
Thanks for your work !
As suggested earlier in the 'virtqueue coalescing' thread, I will be
working on top of your patch. :)
在 2023/2/19 下午5:03, Alvaro Karsz 写道:
This patch makes several improvements to the notification coalescing
feature, including:
- Consolidating virtio_net_ct
在 2023/2/21 下午7:48, David Edmondson 写道:
On Tuesday, 2023-02-21 at 16:38:52 +08, Heng Qi wrote:
...
+A device MAY set the coalescing parameter to a value close to a power of 2
value.
What is this about?
If it is intended to indicate that a device may use a value different to
that passed by
在 2023/2/21 下午8:47, Parav Pandit 写道:
From: virtio-comm...@lists.oasis-open.org On Behalf Of Heng Qi
Also, a feature bit VIRTIO_NET_F_HASH_REPORT_TUNNEL are added to
report an encapsulation type, and the feature depends on
VIRTIO_NET_F_HASH_REPORT.
As we discussed that tunnel type alone is
在 2023/2/21 下午8:47, Parav Pandit 写道:
From: virtio-comm...@lists.oasis-open.org On Behalf Of Heng Qi
Also, a feature bit VIRTIO_NET_F_HASH_REPORT_TUNNEL are added to
report an encapsulation type, and the feature depends on
VIRTIO_NET_F_HASH_REPORT.
As we discussed that tunnel type alone is
在 2023/2/22 上午7:18, Michael S. Tsirkin 写道:
On Tue, Feb 21, 2023 at 10:32:11PM +, Parav Pandit wrote:
From: Michael S. Tsirkin
Sent: Tuesday, February 21, 2023 4:46 PM
What is this information driver can't observe? It sees all the packets after
all,
we are not stripping tunneling header
Hi, Jason. Long time no see. :)
在 2023/2/22 上午11:22, Jason Wang 写道:
在 2023/2/22 01:50, Michael S. Tsirkin 写道:
On Sat, Feb 18, 2023 at 10:37:15PM +0800, Heng Qi wrote:
+\subparagraph{Security risks between encapsulated packets and RSS}
+There may be potential security risks when encapsulated
在 2023/2/22 下午2:21, Michael S. Tsirkin 写道:
On Wed, Feb 22, 2023 at 10:34:39AM +0800, Heng Qi wrote:
The user will figure out how to mitigate when such QoS is not available. Either
to run in best-effort mode or mitigate differently.
Yes, our cloud security and cloud network team will
Hi, Parav.
在 2023/2/22 下午10:28, Parav Pandit 写道:
From: Michael S. Tsirkin
Sent: Wednesday, February 22, 2023 1:29 AM
MMIO device has vq_index register too.
I am inclined to vq_index given current state of spec
[mst@tuck virtio]$ git grep vq_index|wc -l
0
:)
Grep for "virtqueue index".
We
在 2023/2/23 上午10:50, Jason Wang 写道:
Hi:
在 2023/2/22 14:46, Heng Qi 写道:
Hi, Jason. Long time no see. :)
在 2023/2/22 上午11:22, Jason Wang 写道:
在 2023/2/22 01:50, Michael S. Tsirkin 写道:
On Sat, Feb 18, 2023 at 10:37:15PM +0800, Heng Qi wrote:
+\subparagraph{Security risks between
在 2023/2/23 下午9:13, Michael S. Tsirkin 写道:
On Sat, Feb 18, 2023 at 10:37:15PM +0800, Heng Qi wrote:
+\subparagraph{Security risks between encapsulated packets and RSS}
+There may be potential security risks when encapsulated packets using RSS to
+select queues for placement.
Is this just
在 2023/2/24 上午10:45, Jason Wang 写道:
在 2023/2/23 12:41, Heng Qi 写道:
在 2023/2/23 上午10:50, Jason Wang 写道:
Hi:
在 2023/2/22 14:46, Heng Qi 写道:
Hi, Jason. Long time no see. :)
在 2023/2/22 上午11:22, Jason Wang 写道:
在 2023/2/22 01:50, Michael S. Tsirkin 写道:
On Sat, Feb 18, 2023 at 10:37:15PM
在 2023/2/24 下午4:13, Michael S. Tsirkin 写道:
On Thu, Feb 23, 2023 at 02:40:46PM +, Parav Pandit wrote:
From: Michael S. Tsirkin
Sent: Thursday, February 23, 2023 8:14 AM
On Sat, Feb 18, 2023 at 10:37:15PM +0800, Heng Qi wrote:
So for RSS specifically, we brain-stormed with Amnon
在 2023/2/27 下午4:35, Jason Wang 写道:
On Mon, Feb 27, 2023 at 3:39 PM Michael S. Tsirkin wrote:
On Mon, Feb 27, 2023 at 12:07:17PM +0800, Jason Wang wrote:
Btw, this kind of 1:1 hash features seems not scalable and flexible.
It requires an endless extension on bits/fields. Modern NICs allow th
在 2023/2/28 上午4:19, Michael S. Tsirkin 写道:
On Mon, Feb 27, 2023 at 08:45:43PM +0200, Alvaro Karsz wrote:
-If the VIRTIO_NET_F_NOTF_COAL feature is negotiated, the driver can
-send control commands for dynamically changing the coalescing parameters.
+If the VIRTIO_NET_F_NOTF_COAL feature is ne
在 2023/2/28 下午3:49, Michael S. Tsirkin 写道:
On Tue, Feb 28, 2023 at 10:41:18AM +0800, Heng Qi wrote:
The problem is the global qualifier. And it's not even global -
there are two sets for rx and for tx and does not apply to cvq at all.
How about "RX/TX coalescing parameters&q
fload).
This is impossible with the approach proposed here.
I'm not actually objecting. And at least we then don't need to
worry about leaking info - it's not virtio leaking info
it's the bpf program. I wonder what does Heng Qi think.
Heng Qi would it work for your scenario?
We are
在 2023/2/28 下午7:16, Michael S. Tsirkin 写道:
On Sat, Feb 18, 2023 at 10:37:15PM +0800, Heng Qi wrote:
If the tunnel is used to encapsulate the packets, the hash calculated
using the outer header of the receive packets is always fixed for the
same flow packets, i.e. they will be steered to the
在 2023/2/28 下午7:16, Michael S. Tsirkin 写道:
On Sat, Feb 18, 2023 at 10:37:15PM +0800, Heng Qi wrote:
If the tunnel is used to encapsulate the packets, the hash calculated
using the outer header of the receive packets is always fixed for the
same flow packets, i.e. they will be steered to the
virtqueue
is busy and another virtqueue is idle, then it will be very useful to
control coalescing parameters at the virtqueue granularity.
[1] https://docs.kernel.org/networking/net_dim.html
Signed-off-by: Heng Qi
Reviewed-by: Xuan Zhuo
---
This patch is on top of Alvaro's latest v7 patch:
在 2023/3/1 下午7:07, Michael S. Tsirkin 写道:
On Wed, Mar 01, 2023 at 11:30:37AM +0800, Heng Qi wrote:
在 2023/2/28 下午7:16, Michael S. Tsirkin 写道:
On Sat, Feb 18, 2023 at 10:37:15PM +0800, Heng Qi wrote:
If the tunnel is used to encapsulate the packets, the hash calculated
using the outer
在 2023/3/7 上午6:57, Michael S. Tsirkin 写道:
On Thu, Mar 02, 2023 at 11:36:18AM +, David Edmondson wrote:
+for an enabled transmit/receive
virtqueue whose number is \field{vqn}.
Should this now be "whose index is \field{vqn}"?
Ugh. I guess we'll ha
在 2023/3/9 上午6:30, Parav Pandit 写道:
From: virtio-dev@lists.oasis-open.org On
Behalf Of Heng Qi
Sent: Thursday, March 2, 2023 10:27 PM
I remember we discussed that instead of mentioning each individual field,
better to describe the whole structure being read-only or write-only.
Consider
在 2023/3/8 下午10:39, Michael S. Tsirkin 写道:
On Wed, Mar 01, 2023 at 10:56:31AM +0800, Heng Qi wrote:
在 2023/2/28 下午7:16, Michael S. Tsirkin 写道:
On Sat, Feb 18, 2023 at 10:37:15PM +0800, Heng Qi wrote:
If the tunnel is used to encapsulate the packets, the hash calculated
using the outer
在 2023/2/28 下午7:16, Michael S. Tsirkin 写道:
On Sat, Feb 18, 2023 at 10:37:15PM +0800, Heng Qi wrote:
If the tunnel is used to encapsulate the packets, the hash calculated
using the outer header of the receive packets is always fixed for the
same flow packets, i.e. they will be steered to the
在 2023/3/10 上午3:36, Michael S. Tsirkin 写道:
On Thu, Mar 09, 2023 at 12:55:02PM +0800, Heng Qi wrote:
在 2023/3/8 下午10:39, Michael S. Tsirkin 写道:
On Wed, Mar 01, 2023 at 10:56:31AM +0800, Heng Qi wrote:
在 2023/2/28 下午7:16, Michael S. Tsirkin 写道:
On Sat, Feb 18, 2023 at 10:37:15PM +0800
在 2023/3/15 下午7:58, Michael S. Tsirkin 写道:
On Sat, Mar 11, 2023 at 11:23:08AM +0800, Heng Qi wrote:
在 2023/3/10 上午3:36, Michael S. Tsirkin 写道:
On Thu, Mar 09, 2023 at 12:55:02PM +0800, Heng Qi wrote:
在 2023/3/8 下午10:39, Michael S. Tsirkin 写道:
On Wed, Mar 01, 2023 at 10:56:31AM +0800
在 2023/3/15 上午11:23, Parav Pandit 写道:
On 3/6/2023 10:48 AM, Heng Qi wrote:
+\item[VIRTIO_NET_F_HASH_TUNNEL(52)] Device supports inner header hash
May be to say inner packet header hash..
This make its little more clear about "which header" that you
explained in the
在 2023/3/15 下午8:10, Michael S. Tsirkin 写道:
On Tue, Mar 14, 2023 at 11:23:55PM -0400, Parav Pandit wrote:
If not, for now it may be better to skip vxlan and nvegre as they inherently
have unique outer header UDP src port based on the inner header.
So what's left, GRE? GRE is actually differe
On Wed, Mar 15, 2023 at 10:57:40AM -0400, Michael S. Tsirkin wrote:
> On Wed, Mar 15, 2023 at 08:55:45PM +0800, Heng Qi wrote:
> >
> >
> > 在 2023/3/15 下午7:58, Michael S. Tsirkin 写道:
> > > On Sat, Mar 11, 2023 at 11:23:08AM +0800, Heng Qi wrote:
> > >
在 2023/3/15 下午11:09, Michael S. Tsirkin 写道:
On Wed, Mar 15, 2023 at 09:19:43PM +0800, Heng Qi wrote:
Any encapsulation technology that includes UDP/L4 header likely do not
prefer based on the inner header. This is because the outer header src
port entropy is added based on the inner header
On Wed, Mar 15, 2023 at 07:06:53PM -0400, Parav Pandit wrote:
>
>
> On 3/15/2023 9:19 AM, Heng Qi wrote:
> >
> >
> >在 2023/3/15 上午11:23, Parav Pandit 写道:
> >>
> >>
> >>On 3/6/2023 10:48 AM, Heng Qi wrote:
> >>
> [..]
> &g
在 2023/3/16 上午7:24, Parav Pandit 写道:
On 3/15/2023 8:10 AM, Michael S. Tsirkin wrote:
On Tue, Mar 14, 2023 at 11:23:55PM -0400, Parav Pandit wrote:
If not, for now it may be better to skip vxlan and nvegre as they
inherently
have unique outer header UDP src port based on the inner header.
在 2023/3/23 上午1:02, Parav Pandit 写道:
From: Michael S. Tsirkin
Sent: Wednesday, March 22, 2023 12:53 PM
On Wed, Mar 22, 2023 at 04:49:58PM +, Parav Pandit wrote:
From: Michael S. Tsirkin
Sent: Wednesday, March 22, 2023 12:47 PM
I agree with Cornelia here. Yes if devices do not want to
在 2023/3/23 上午11:13, Parav Pandit 写道:
From: Michael S. Tsirkin
Sent: Wednesday, March 22, 2023 12:42 PM
Yes. But my point is this. Some flows can be IPv4 others IPv6.
Do you see a way to have a key that will result in a symmetrical hash for both
IPv4 and IPv6? Can you give an example plea
在 2023/3/23 上午11:58, Heng Qi 写道:
在 2023/3/23 上午11:13, Parav Pandit 写道:
From: Michael S. Tsirkin
Sent: Wednesday, March 22, 2023 12:42 PM
Yes. But my point is this. Some flows can be IPv4 others IPv6.
Do you see a way to have a key that will result in a symmetrical
hash for both
IPv4 and
在 2023/3/21 上午3:45, Michael S. Tsirkin 写道:
On Thu, Mar 16, 2023 at 09:17:26PM +0800, Heng Qi wrote:
On Wed, Mar 15, 2023 at 10:57:40AM -0400, Michael S. Tsirkin wrote:
On Wed, Mar 15, 2023 at 08:55:45PM +0800, Heng Qi wrote:
在 2023/3/15 下午7:58, Michael S. Tsirkin 写道:
On Sat, Mar 11, 2023
在 2023/3/21 上午3:48, Michael S. Tsirkin 写道:
On Wed, Mar 15, 2023 at 08:55:45PM +0800, Heng Qi wrote:
We use the most basic GRE header fields (not NVGRE), not even optional
fields.
I'd say yes, the most convincing usecase is with legacy GRE.
Yes. But we still have a strong need for
在 2023/4/8 下午6:29, Michael S. Tsirkin 写道:
On Thu, Mar 30, 2023 at 08:37:21PM +0800, Heng Qi wrote:
在 2023/3/21 上午3:48, Michael S. Tsirkin 写道:
On Wed, Mar 15, 2023 at 08:55:45PM +0800, Heng Qi wrote:
We use the most basic GRE header fields (not NVGRE), not even optional
fields.
I'
在 2023/4/12 上午5:03, Parav Pandit 写道:
On 4/3/2023 12:58 AM, Heng Qi wrote:
To achieve this, the device can calculate a suitable hash based on
the inner headers
of this flow, for example using the Toeplitz combined with a
symmetric hash key.
I am not sure you need symmetric hash key
在 2023/4/14 上午5:43, Michael S. Tsirkin 写道:
On Thu, Apr 13, 2023 at 07:03:26PM +0800, Heng Qi wrote:
For example, when the packets of certain
+tunnels are spread across multiple receive queues, these receive
queues may have an unbalanced
+amount of packets. This can cause a specific
在 2023/4/14 上午11:10, Jason Wang 写道:
On Fri, Apr 14, 2023 at 5:46 AM Michael S. Tsirkin wrote:
On Thu, Apr 13, 2023 at 07:03:26PM +0800, Heng Qi wrote:
For example, when the packets of certain
+tunnels are spread across multiple receive queues, these receive
queues may have an unbalanced
在 2023/4/26 上午4:28, Parav Pandit 写道:
On 4/23/2023 3:35 AM, Heng Qi wrote:
\subsubsection{Legacy Interface: Feature bits}\label{sec:Device
Types / Network Device / Feature bits / Legacy Interface: Feature bits}
@@ -198,6 +202,7 @@ \subsection{Device configuration
layout}\label
在 2023/4/26 下午10:24, Parav Pandit 写道:
From: Heng Qi
Sent: Wednesday, April 26, 2023 10:04 AM
Yes, but that seems like a tiny cost, and the cvq command-related structure is
much simpler.
Current structure size is 24 bytes.
This size becomes multiplier with device count scale to be always
在 2023/4/26 下午10:48, Michael S. Tsirkin 写道:
On Wed, Apr 26, 2023 at 10:14:30PM +0800, Heng Qi wrote:
This does not mean that every device needs to implement and support all of
these, they can choose to support some protocols they want.
I add these because we have scale application scenarios
On Thu, Apr 27, 2023 at 01:13:29PM -0400, Michael S. Tsirkin wrote:
> On Thu, Apr 27, 2023 at 10:28:29AM +0800, Heng Qi wrote:
> >
> >
> > 在 2023/4/26 下午10:48, Michael S. Tsirkin 写道:
> > > On Wed, Apr 26, 2023 at 10:14:30PM +0800, Heng Qi wrote:
> > > >
1 - 100 of 119 matches
Mail list logo
