search for: max_virtqueue_pair

On Mon, Aug 17, 2015 at 10:43:46AM +0800, Jason Wang wrote: > > > On 08/16/2015 09:42 PM, Victor Kaplansky wrote: > > Clarify general description of the mac, status and > > max_virtqueue_pairs fields. Specifically, the old description is > > vague about configuration layout and fields offsets when some of > > the fields are non valid. > > > > Also clarify that validity of two status bits depends on two > > different feature flags. > > > > Signed...

On Mon, Aug 17, 2015 at 10:43:46AM +0800, Jason Wang wrote: > > > On 08/16/2015 09:42 PM, Victor Kaplansky wrote: > > Clarify general description of the mac, status and > > max_virtqueue_pairs fields. Specifically, the old description is > > vague about configuration layout and fields offsets when some of > > the fields are non valid. > > > > Also clarify that validity of two status bits depends on two > > different feature flags. > > > > Signed...

Clarify general description of the mac, status and max_virtqueue_pairs fields. Specifically, the old description is vague about configuration layout and fields offsets when some of the fields are non valid. Also clarify that validity of two status bits depends on two different feature flags. Signed-off-by: Victor Kaplansky <victork at redhat.com> --- content...

This set of two patches adds a new field called default_mtu to the configuration area of network devices. The motivation is to allow libvirt to set initial MTU different from 1500 on guests virtual NICs. We also propose to use this new field to report MTU changes by the guest OS to the device to facilitate debugging and mtu tunning. The first patch just clarify the definition of existing fields

This set of two patches adds a new field called default_mtu to the configuration area of network devices. The motivation is to allow libvirt to set initial MTU different from 1500 on guests virtual NICs. We also propose to use this new field to report MTU changes by the guest OS to the device to facilitate debugging and mtu tunning. The first patch just clarify the definition of existing fields

On 08/19/2015 07:54 PM, Victor Kaplansky wrote: > On Mon, Aug 17, 2015 at 10:43:46AM +0800, Jason Wang wrote: >> >> On 08/16/2015 09:42 PM, Victor Kaplansky wrote: >>> Clarify general description of the mac, status and >>> max_virtqueue_pairs fields. Specifically, the old description is >>> vague about configuration layout and fields offsets when some of >>> the fields are non valid. >>> >>> Also clarify that validity of two status bits depends on two >>> different feature flags. >>&gt...

Add multiqueue support to virtio network device. Add a new feature flag VIRTIO_NET_F_MQ for this feature, a new configuration field max_virtqueue_pairs to detect supported number of virtqueues as well as a new command VIRTIO_NET_CTRL_MQ to program packet steering for unidirectional protocols. --- Changes in v6: - rename RFS -> multiqueue to avoid confusion with RFS in linux mention automatic receive steering as Rusty suggested Changes in...

Add multiqueue support to virtio network device. Add a new feature flag VIRTIO_NET_F_MQ for this feature, a new configuration field max_virtqueue_pairs to detect supported number of virtqueues as well as a new command VIRTIO_NET_CTRL_MQ to program packet steering for unidirectional protocols. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- Changes in v7: - 8000h -> 0x8000 at Rusty's request Changes in v6: - rename RFS -...

Add multiqueue support to virtio network device. Add a new feature flag VIRTIO_NET_F_MQ for this feature, a new configuration field max_virtqueue_pairs to detect supported number of virtqueues as well as a new command VIRTIO_NET_CTRL_MQ to program packet steering for unidirectional protocols. --- Changes in v6: - rename RFS -> multiqueue to avoid confusion with RFS in linux mention automatic receive steering as Rusty suggested Changes in...

Add multiqueue support to virtio network device. Add a new feature flag VIRTIO_NET_F_MQ for this feature, a new configuration field max_virtqueue_pairs to detect supported number of virtqueues as well as a new command VIRTIO_NET_CTRL_MQ to program packet steering for unidirectional protocols. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- Changes in v7: - 8000h -> 0x8000 at Rusty's request Changes in v6: - rename RFS -...

On 08/16/2015 09:42 PM, Victor Kaplansky wrote: > Clarify general description of the mac, status and > max_virtqueue_pairs fields. Specifically, the old description is > vague about configuration layout and fields offsets when some of > the fields are non valid. > > Also clarify that validity of two status bits depends on two > different feature flags. > > Signed-off-by: Victor Kaplansky <victo...

Add RFS support to virtio network device. Add a new feature flag VIRTIO_NET_F_RFS for this feature, a new configuration field max_virtqueue_pairs to detect supported number of virtqueues as well as a new command VIRTIO_NET_CTRL_RFS to program packet steering for unidirectional protocols. --- Changes from v4: - address Jason's comments - have configuration specify the number of VQ pairs and not pairs - 1 Changes from v3: - rename mult...

Add RFS support to virtio network device. Add a new feature flag VIRTIO_NET_F_RFS for this feature, a new configuration field max_virtqueue_pairs to detect supported number of virtqueues as well as a new command VIRTIO_NET_CTRL_RFS to program packet steering for unidirectional protocols. --- Changes from v4: - address Jason's comments - have configuration specify the number of VQ pairs and not pairs - 1 Changes from v3: - rename mult...

Add multiqueue support to virtio network device. Add a new feature flag VIRTIO_NET_F_MQ for this feature, a new configuration field max_virtqueue_pairs to detect supported number of virtqueues as well as a new command VIRTIO_NET_CTRL_MQ to program packet steering for unidirectional protocols. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- Changes in v8: - Fix value for CTRL_MQ command Changes in v7: - 8000h -> 0x8000 at Ru...

Add multiqueue support to virtio network device. Add a new feature flag VIRTIO_NET_F_MQ for this feature, a new configuration field max_virtqueue_pairs to detect supported number of virtqueues as well as a new command VIRTIO_NET_CTRL_MQ to program packet steering for unidirectional protocols. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- Changes in v8: - Fix value for CTRL_MQ command Changes in v7: - 8000h -> 0x8000 at Ru...

...> /* See VIRTIO_NET_F_STATUS and VIRTIO_NET_S_* above */ > - __u16 status; > + __virtio16 status; > /* Maximum number of each of transmit and receive queues; > * see VIRTIO_NET_F_MQ and VIRTIO_NET_CTRL_MQ. > * Legal values are between 1 and 0x8000 > */ > - __u16 max_virtqueue_pairs; > + __virtio16 max_virtqueue_pairs; > /* Default maximum transmit unit advice */ > - __u16 mtu; > + __virtio16 mtu; > /* > * speed, in units of 1Mb. All values 0 to INT_MAX are legal. > * Any other value stands for unknown. > */ > - __u32 speed; > + __vi...

...l value and reports MTU changes to the device. + \end{description} \subsubsection{Feature bit requirements}\label{sec:Device Types / Network Device / Feature bits / Feature bit requirements} @@ -3128,6 +3134,7 @@ struct virtio_net_config { u8 mac[6]; le16 status; le16 max_virtqueue_pairs; + le16 default_mtu; }; \end{lstlisting} @@ -3158,6 +3165,15 @@ by the driver after negotiation. \field{max_virtqueue_pairs} is valid only if VIRTIO_NET_F_MQ is set and can be read by the driver. +\item [\field{default_mtu}] is a hint to the driver set by the + device. It...

On Mon, Aug 17, 2015 at 11:07:15AM +0800, Jason Wang wrote: > > > On 08/16/2015 09:42 PM, Victor Kaplansky wrote: > > @@ -3128,6 +3134,7 @@ struct virtio_net_config { > > u8 mac[6]; > > le16 status; > > le16 max_virtqueue_pairs; > > + le16 default_mtu; > > Looks like "mtu" is ok, consider we use "mac" instead of "default_mac". Good point. I'll change the name in the next version of the patch. > > > }; > > \end{lstlisting} > > > > @@ -...

On Mon, Aug 17, 2015 at 11:07:15AM +0800, Jason Wang wrote: > > > On 08/16/2015 09:42 PM, Victor Kaplansky wrote: > > @@ -3128,6 +3134,7 @@ struct virtio_net_config { > > u8 mac[6]; > > le16 status; > > le16 max_virtqueue_pairs; > > + le16 default_mtu; > > Looks like "mtu" is ok, consider we use "mac" instead of "default_mac". Good point. I'll change the name in the next version of the patch. > > > }; > > \end{lstlisting} > > > > @@ -...

...TIO_NET_F_MTU 25 /* Device supports Default MTU Negotiation */ > > #ifndef VIRTIO_NET_NO_LEGACY > #define VIRTIO_NET_F_GSO 6 /* Host handles pkts w/ any GSO type */ > @@ -73,6 +74,8 @@ struct virtio_net_config { > * Legal values are between 1 and 0x8000 > */ > __u16 max_virtqueue_pairs; > + /* Default maximum transmit unit advice */ > + __u16 mtu; > } __attribute__((packed)); > > /* You can't change user visible headers without breaking ABI. This structure might be used by other user code. Also how can this work if host is using old size of structure.