search for: iov_max

I'm having a bit of misbehavior wherein Dovecot seems to refuse to cooperate with my Mulberry MUA. By and large, everything works great. I can move mail back and forth happily. I can compose a note and copy the outgoing mail to my Dovecot "Sent" folder using my default Mulberry settings. But if I reply or forward a mail, I get a Mulberry error popup saying that it

...n >> > their assumptions, unless specific device features indicate that >> > general layout is permitted using VIRTIO_F_ANY_LAYOUT. In >> > addition, some implementations may have large-but-reasonable >> > restrictions on total descriptor size (such as based on IOV_MAX >> > in the host OS). This has not been a problem in practice: little >> > sympathy will be given to drivers which create unreasonably-sized >> > descriptors such as dividing a network packet into 1500 >> > single-byte descriptors! >> >> That's f...

...n >> > their assumptions, unless specific device features indicate that >> > general layout is permitted using VIRTIO_F_ANY_LAYOUT. In >> > addition, some implementations may have large-but-reasonable >> > restrictions on total descriptor size (such as based on IOV_MAX >> > in the host OS). This has not been a problem in practice: little >> > sympathy will be given to drivers which create unreasonably-sized >> > descriptors such as dividing a network packet into 1500 >> > single-byte descriptors! >> >> That's f...

...ended that drivers be conservative in > their assumptions, unless specific device features indicate that > general layout is permitted using VIRTIO_F_ANY_LAYOUT. In > addition, some implementations may have large-but-reasonable > restrictions on total descriptor size (such as based on IOV_MAX > in the host OS). This has not been a problem in practice: little > sympathy will be given to drivers which create unreasonably-sized > descriptors such as dividing a network packet into 1500 > single-byte descriptors! That's fine with me too. So which bit are we using for this? I...

...ended that drivers be conservative in > their assumptions, unless specific device features indicate that > general layout is permitted using VIRTIO_F_ANY_LAYOUT. In > addition, some implementations may have large-but-reasonable > restrictions on total descriptor size (such as based on IOV_MAX > in the host OS). This has not been a problem in practice: little > sympathy will be given to drivers which create unreasonably-sized > descriptors such as dividing a network packet into 1500 > single-byte descriptors! That's fine with me too. So which bit are we using for this? I...

On 2019/10/13 ??4:27, Michael S. Tsirkin wrote: > On Sat, Oct 12, 2019 at 03:28:49PM +0800, Jason Wang wrote: >> On 2019/10/11 ??9:45, Michael S. Tsirkin wrote: >>> The idea is to support multiple ring formats by converting >>> to a format-independent array of descriptors. >>> >>> This costs extra cycles, but we gain in ability >>> to fetch a

On 2019/10/13 ??4:27, Michael S. Tsirkin wrote: > On Sat, Oct 12, 2019 at 03:28:49PM +0800, Jason Wang wrote: >> On 2019/10/11 ??9:45, Michael S. Tsirkin wrote: >>> The idea is to support multiple ring formats by converting >>> to a format-independent array of descriptors. >>> >>> This costs extra cycles, but we gain in ability >>> to fetch a

...possible issue, if we try to batch descriptor chain when we've > already batched some descriptors, we may reach the limit then some of the > descriptors might need re-read. > > Or we may need circular index (head, tail) in this case? > > Thanks We never supported more than IOV_MAX descriptors. And we don't batch more than iov_limit - IOV_MAX. so buffer never overflows. -- MST

...vers be conservative in their assumptions, unless specific device features indicate that general layout is permitted, such VIRTIO_NET_F_ANY_LAYOUT or VIRTIO_BLK_F_ANY_LAYOUT. In addition, some implementations may have large-but-reasonable restrictions on total descriptor size (such as based on IOV_MAX in the host OS). This has not been a problem in practice: little sympathy will be given to drivers which create unreasonably-sized descriptors such as by dividing a network packet into 1500 single-byte descriptors! === Notes: 1) The restrictions are still in place by default. 2) We introduce VI...

...vers be conservative in their assumptions, unless specific device features indicate that general layout is permitted, such VIRTIO_NET_F_ANY_LAYOUT or VIRTIO_BLK_F_ANY_LAYOUT. In addition, some implementations may have large-but-reasonable restrictions on total descriptor size (such as based on IOV_MAX in the host OS). This has not been a problem in practice: little sympathy will be given to drivers which create unreasonably-sized descriptors such as by dividing a network packet into 1500 single-byte descriptors! === Notes: 1) The restrictions are still in place by default. 2) We introduce VI...

Il 01/07/2013 01:47, Rusty Russell ha scritto: > > > > > > Mainly because I'm not sure that *all* devices are now safe. Are they? > > > > virtio-scsi's implementation in QEMU is not safe (been delaying that for > > too long, sorry), but the spec is safe. > > Then if we added a transport feature, we couldn't use it :( Transport feature bits

Il 01/07/2013 01:47, Rusty Russell ha scritto: > > > > > > Mainly because I'm not sure that *all* devices are now safe. Are they? > > > > virtio-scsi's implementation in QEMU is not safe (been delaying that for > > too long, sorry), but the spec is safe. > > Then if we added a transport feature, we couldn't use it :( Transport feature bits

...1.2.0 23.04.2012 *) éÓÐÒÁ×ÌÅÎÉÅ: × ÒÁÂÏÞÅÍ ÐÒÏÃÅÓÓÅ ÍÏÇ ÐÒÏÉÚÏÊÔÉ segmentation fault, ÅÓÌÉ ÉÓÐÏÌØÚÏ×ÁÌÁÓØ ÄÉÒÅËÔÉ×Á try_files; ÏÛÉÂËÁ ÐÏÑ×ÉÌÁÓØ × 1.1.19. *) éÓÐÒÁ×ÌÅÎÉÅ: ÏÔ×ÅÔ ÍÏÇ ÂÙÔØ ÐÅÒÅÄÁÎ ÎÅ ÐÏÌÎÏÓÔØÀ, ÅÓÌÉ ÉÓÐÏÌØÚÏ×ÁÌÏÓØ ÂÏÌØÛÅ IOV_MAX ÂÕÆÅÒÏ×. *) éÓÐÒÁ×ÌÅÎÉÅ: × ÒÁÂÏÔÅ ÐÁÒÁÍÅÔÒÁ crop ÄÉÒÅËÔÉ×Ù image_filter. óÐÁÓÉÂÏ Maxim Bublis. Maxim Dounin

...g. It is thus recommended that drivers be conservative in their assumptions, unless specific device features indicate that general layout is permitted using VIRTIO_F_ANY_LAYOUT. In addition, some implementations may have large-but-reasonable restrictions on total descriptor size (such as based on IOV_MAX in the host OS). This has not been a problem in practice: little sympathy will be given to drivers which create unreasonably-sized descriptors such as dividing a network packet into 1500 single-byte descriptors!

...e conservative in > > their assumptions, unless specific device features indicate that > > general layout is permitted using VIRTIO_F_ANY_LAYOUT. In > > addition, some implementations may have large-but-reasonable > > restrictions on total descriptor size (such as based on IOV_MAX > > in the host OS). This has not been a problem in practice: little > > sympathy will be given to drivers which create unreasonably-sized > > descriptors such as dividing a network packet into 1500 > > single-byte descriptors! > > That's fine with me too. > So...

...; their assumptions, unless specific device features indicate that > >> > general layout is permitted using VIRTIO_F_ANY_LAYOUT. In > >> > addition, some implementations may have large-but-reasonable > >> > restrictions on total descriptor size (such as based on IOV_MAX > >> > in the host OS). This has not been a problem in practice: little > >> > sympathy will be given to drivers which create unreasonably-sized > >> > descriptors such as dividing a network packet into 1500 > >> > single-byte descriptors! > >&g...

...> their assumptions, unless specific device features indicate that > general layout is permitted, such VIRTIO_NET_F_ANY_LAYOUT or > VIRTIO_BLK_F_ANY_LAYOUT. In addition, some implementations may > have large-but-reasonable restrictions on total descriptor size > (such as based on IOV_MAX in the host OS). This has not been a > problem in practice: little sympathy will be given to drivers > which create unreasonably-sized descriptors such as by dividing a > network packet into 1500 single-byte descriptors! > === > > Notes: > 1) The restrictions are still in p...

On Thu, Jun 13, 2013 at 11:02:59AM +0300, Michael S. Tsirkin wrote: > On Thu, Jun 13, 2013 at 02:12:22PM +0930, Rusty Russell wrote: > > "Michael S. Tsirkin" <mst at redhat.com> writes: > > > On Thu, Mar 14, 2013 at 04:15:28PM +0100, Paolo Bonzini wrote: > > >> Il 14/03/2013 12:10, Michael S. Tsirkin ha scritto: > > >> > Add field for

On Thu, Jun 13, 2013 at 11:02:59AM +0300, Michael S. Tsirkin wrote: > On Thu, Jun 13, 2013 at 02:12:22PM +0930, Rusty Russell wrote: > > "Michael S. Tsirkin" <mst at redhat.com> writes: > > > On Thu, Mar 14, 2013 at 04:15:28PM +0100, Paolo Bonzini wrote: > > >> Il 14/03/2013 12:10, Michael S. Tsirkin ha scritto: > > >> > Add field for

I hacked zstd support into OpenSSH a while ago and just started to clean it up in the recent days. The cleanup includes configuration support among other things that I did not have. During testing I noticed the following differences compared to zlib: - highly interactive shell output (as in refreshed at a _very_ high rate) may result in higher bandwidth compared to zlib. Since zstd is quicker