Hi,
So there were a couple of issues with my and your patch:
1) We should NOT be using straight *malloc*() to allocate 17 pages of
memory. It needs to be page-aligned, so *aligned_alloc()* is the correct
choice.
2) I missed recognizing that we also need to *free()* instead of
*free_page()* in the right place.
Please see improved patch - better hack ;-). I still think we might be
allocating 17-too many 17-pages large buffers. But at least we recognize
VIRTIO_NET_F_MRG_RXBUF is off/on and choose correct page size accordingly
(more/less).
diff --git a/drivers/virtio-net.cc b/drivers/virtio-net.cc
index e78fb3af..0df45dce 100644
--- a/drivers/virtio-net.cc
+++ b/drivers/virtio-net.cc
@@ -63,6 +63,7 @@ extern int maxnic;
namespace virtio {
int net::_instance = 0;
+bool net::use_large_buffer = false;
#define net_tag "virtio-net"
#define net_d(...) tprintf_d(net_tag, __VA_ARGS__)
@@ -375,6 +376,9 @@ void net::read_config()
net_i("Features: %s=%d,%s=%d", "Host TSO ECN", _host_tso_ecn, "CSUM",
_csum);
net_i("Features: %s=%d,%s=%d", "Guest_csum", _guest_csum, "guest
tso4", _guest_tso4);
net_i("Features: %s=%d", "host tso4", _host_tso4);
+
+ printf("VIRTIO_NET_F_MRG_RXBUF: %d\n", _mergeable_bufs);
+ use_large_buffer = !_mergeable_bufs;
}
/**
@@ -473,7 +477,10 @@ void net::receiver()
// Bad packet/buffer - discard and continue to the next one
if (len < _hdr_size + ETHER_HDR_LEN) {
rx_drops++;
- memory::free_page(page);
+ if (use_large_buffer)
+ free(page);
+ else
+ memory::free_page(page);
continue;
}
@@ -581,7 +588,13 @@ void net::free_buffer_and_refcnt(void* buffer, void*
refcnt)
void net::do_free_buffer(void* buffer)
{
buffer = align_down(buffer, page_size);
- memory::free_page(buffer);
+ if (use_large_buffer) {
+ printf("--> Freeing 17 pages: %p\n", buffer);
+ free(buffer);
+ } else {
+ printf("--> Freeing single page: %p\n", buffer);
+ memory::free_page(buffer);
+ }
}
void net::fill_rx_ring()
@@ -591,12 +604,23 @@ void net::fill_rx_ring()
vring* vq = _rxq.vqueue;
while (vq->avail_ring_not_empty()) {
- auto page = memory::alloc_page();
+ void *page;
+ int pages_num = use_large_buffer ? 17 : 1;
+ if (use_large_buffer) {
+ page = aligned_alloc(memory::page_size, pages_num *
memory::page_size);
+ printf("--> Allocated 17 pages: %p\n", page);
+ } else {
+ page = memory::alloc_page();
+ printf("--> Allocated single page: %p\n", page);
+ }
vq->init_sg();
- vq->add_in_sg(page, memory::page_size);
+ vq->add_in_sg(page, pages_num * memory::page_size);
if (!vq->add_buf(page)) {
- memory::free_page(page);
+ if (use_large_buffer)
+ free(page);
+ else
+ memory::free_page(page);
break;
}
added++;
diff --git a/drivers/virtio-net.hh b/drivers/virtio-net.hh
index adc93b39..e6725231 100644
--- a/drivers/virtio-net.hh
+++ b/drivers/virtio-net.hh
@@ -220,6 +220,7 @@ public:
static void free_buffer_and_refcnt(void* buffer, void* refcnt);
static void free_buffer(iovec iov) { do_free_buffer(iov.iov_base); }
static void do_free_buffer(void* buffer);
+ static bool use_large_buffer;
bool ack_irq();
I have tested it with your python example downloading 100 times 5MB large
file and all seems to be working fine. Feel free to remove debug statements
:-)
Waldek
On Thursday, September 26, 2019 at 6:12:27 PM UTC-4, Henrique Fingler wrote:
>
> Waldek, I'm getting a general protection fault when doing some HTTP
> requests from OSv, do you think it might be related to the hack to make it
> work on Firecracker?
>
> Here's the MWE, a few requests go through, then it faults.
>
> import urllib.request
> for i in range (10):
> response = urllib.request.urlopen("http://192.168.0.20:9999/1.bin";)
> response.read()
>
> Here's the trace:
>
> [registers]
> RIP: 0x00000000403e9fd6 <memory::page_range_allocator::remove_huge(memory
> ::page_range&)+38>
> RFL: 0x0000000000010202 CS: 0x0000000000000008 SS: 0x0000000000000010
> RAX: 0x000000000000000d RBX: 0xffff800003f2f000 RCX: 0x6d314e7578313731
> RDX: 0x6270415369447065
> RSI: 0xffff800003f2f000 RDI: 0xffff800003f2f008 RBP: 0xffff800000074e20
> R8: 0x00000000000000fc
> R9: 0xffff80000094d7e8 R10: 0x0000000000003f40 R11: 0x1144029210842110
> R12: 0x0000000040911300
> R13: 0xffff80000094d7e8 R14: 0x0000000000003f40 R15: 0x1144029210842110
> RSP: 0xffff800000074e00
> general protection fault
>
>
> [backtrace]
> 0x000000004039cabc <general_protection+140>
> 0x0000000040399fa2 <???+1077518242>
> 0x00000000403e4d66 <memory::page_range_allocator::free(memory::page_range
> *)+166>
> 0x00000000403e4ecb <memory::page_pool::l2::free_batch(memory::page_pool::
> page_batch&)+91>
> 0x00000000403e5118 <memory::page_pool::l2::unfill()+504>
> 0x00000000403e6776 <memory::page_pool::l2::fill_thread()+358>
> 0x00000000403ea7db <std::_Function_handler<void (), memory::page_pool::l2
> ::l2()::{lambda()#1}>::_M_invoke(std::_Any_data const&)+11>
> 0x00000000403f9746 <thread_main_c+38>
> 0x000000004039af62 <???+1077522274>
>
>
> The hack in virtio-net.cc is similar to yours:
>
> diff --git a/drivers/virtio-net.cc b/drivers/virtio-net.cc
> index e78fb3af..0065e8d7 100644
> --- a/drivers/virtio-net.cc
> +++ b/drivers/virtio-net.cc
> @@ -590,13 +590,31 @@ void net::fill_rx_ring()
> int added = 0;
> vring* vq = _rxq.vqueue;
>
> +#define HACKQ 1
> +
> while (vq->avail_ring_not_empty()) {
> - auto page = memory::alloc_page();
> +
> + #if HACKQ
> + auto page = malloc(17 * memory::page_size);
> + #else
> + auto page = memory::alloc_page();
> + #endif
>
> vq->init_sg();
> - vq->add_in_sg(page, memory::page_size);
> +
> + #if HACKQ
> + vq->add_in_sg(page, 17 * memory::page_size);
> + #else
> + vq->add_in_sg(page, memory::page_size);
> + #endif
> +
> if (!vq->add_buf(page)) {
> - memory::free_page(page);
> + #if HACKQ
> + free(page);
> + #else
> + memory::free_page(page);
> + #endif
> +
> break;
> }
> added++;
>
>
> Maybe it's related to the size of the buffer allocated for virtio? I'll
> try to force it to size one and see what happens.
>
> Best.
>
>
> On Friday, September 20, 2019 at 4:01:45 PM UTC-5, Waldek Kozaczuk wrote:
>>
>> Yes quite substantial. On firecracker ZFS needs at least 50-60 ms to
>> initialize on my machine. Whereas RoFS images takes 1 millisecond - the
>> smallest native example takes 5-6 ms to boot including RoFS mount and ~10ms
>> in total to execute (10 ms includes that 5-6 ms of boot time).
>>
>> Sent from my iPhone
>>
>> On Sep 20, 2019, at 15:53, zhiting zhu <[email protected]> wrote:
>>
>> Is there any difference on boot time between zfs and rofs?
>>
>> On Fri, Sep 20, 2019 at 2:45 PM Henrique Fingler <[email protected]>
>> wrote:
>>
>>> I'll check that out.
>>>
>>> Instead of detecting what hypervisor we are dealing with, we should
>>>> simply act accordingly based on what features have been negotiated and
>>>> agreed
>>>
>>>
>>> Yep, you're right. Five minutes after I hit Post I remembered what
>>> "negotiate" means. Whoops.
>>>
>>> Also, I have noticed with my simple patch OSv ends up allocating 256
>>>> buffers on Firecracker
>>>
>>>
>>> That's why I was trying to force the size of the recv queue to one. But
>>> this can be done in a smarter way in net::fill_rx_ring() as you said. I'll
>>> hack around and see what comes up.
>>> It also seems that Firecracker has the machinery to implement
>>> VIRTIO_NET_F_MRG_RXBUF,
>>> but I don't know how complicated it would be to finish it. I might check
>>> that out in a few weeks when I have some free time.
>>>
>>> Thanks for all the pointers!
>>>
>>>
>>> On Friday, September 20, 2019 at 1:58:42 PM UTC-5, Waldek Kozaczuk wrote:
>>>>
>>>>
>>>>
>>>> On Friday, September 20, 2019 at 8:56:35 AM UTC-4, Waldek Kozaczuk
>>>> wrote:
>>>>>
>>>>> See my answers below.
>>>>>
>>>>> On Thursday, September 19, 2019 at 11:34:56 PM UTC-4, Henrique Fingler
>>>>> wrote:
>>>>>>
>>>>>> I agree that this is mostly a thing that should be done on
>>>>>> Firecracker. For now, if there's a way to detect the hypervisor we can
>>>>>> switch that. Personally I'm only using Firecracker so I'll leave this in.
>>>>>>
>>>>> Instead of detecting what hypervisor we are dealing with, we should
>>>>> simply act accordingly based on what features have been negotiated and
>>>>> agreed between OSv (driver) and hypervisor (device). We should simply
>>>>> follow the VirtIo spec as it says here:
>>>>> "5.1.6.3.1 Driver Requirements: Setting Up Receive Buffers
>>>>>
>>>>> - If VIRTIO_NET_F_MRG_RXBUF is not negotiated:
>>>>> - If VIRTIO_NET_F_GUEST_TSO4, VIRTIO_NET_F_GUEST_TSO6 or
>>>>> VIRTIO_NET_F_GUEST_UFO are negotiated, the driver SHOULD populate
>>>>> the
>>>>> receive queue(s) with buffers of at least 65562 bytes.
>>>>> - Otherwise, the driver SHOULD populate the receive queue(s)
>>>>> with buffers of at least 1526 bytes.
>>>>> - If VIRTIO_NET_F_MRG_RXBUF is negotiated, each buffer MUST be at
>>>>> greater than the size of the struct virtio_net_hdr."
>>>>>
>>>>> Something similar to what Linux does here -
>>>>> https://github.com/torvalds/linux/blob/0445971000375859008414f87e7c72fa0d809cf8/drivers/net/virtio_net.c#L3075-L3080.
>>>>>
>>>>> So only use 17 pages long buffers when we have to. One outstanding
>>>>> question
>>>>> is this - shall we allocate and use a single contiguous block of 17 pages
>>>>> of memory as a* single slot *in the vring or *chain of 17 single page
>>>>> ones* like for single large buffer? (the latter is what Linux seems
>>>>> to be doing). The slight advantage of chained one is that it will be
>>>>> easier
>>>>> to find 17 pages of memory than 68K contiguous one under pressure. But
>>>>> handling chained buffer is going to be more complicated. I think memory
>>>>> waste is the same.
>>>>>
>>>>> Pekka, Nadav,
>>>>> What do you think we should do?
>>>>>
>>>>>
>>>>>
>>>>>> I wrote pretty much the same code but instead of *malloc *I used
>>>>>> *memory::alloc_hugepage(
>>>>>> *but it got stuck at compilation when qemu was started, do you
>>>>>> happen to know the reason? I thought we also had to force the length of
>>>>>> the
>>>>>> receiving queue to one, maybe that part was the one breaking osv under
>>>>>> qemu.
>>>>>>
>>>>>
>>>>> Most likely you build the image with ZFS filesystem which at least now
>>>>> requires OSv to boot so that files can be uploaded to. You can avoid it
>>>>> by
>>>>> using Read-Only FS (fs=rofs). Either way, we should use
>>>>> VIRTIO_NET_F_MRG_RXBUF
>>>>> if QEMU offers it (which happens right now) and you patch should not
>>>>> affect
>>>>> this.
>>>>>
>>>>
>>>> Here is a capstan doc that should somewhat explain all 3 filesystems
>>>> OSv offers -
>>>> https://github.com/cloudius-systems/capstan/blob/master/Documentation/OsvFilesystem.md
>>>> .
>>>>
>>>>
>>>>>
>>>>>
>>>>> And the size I was allocating was 17 pages because the spec says
>>>>>> 65562, which is 16 pages plus 26 bytes.
>>>>>>
>>>>> You are right about 17 pages.
>>>>>
>>>>>> Did you also disable VIRTIO_NET_F_MRG_RXBUF in the feature mask or
>>>>>> no, since Firecracker just ignores it?
>>>>>>
>>>>> Firecracker "ignores" it in an sense that it is part of how features
>>>>> are negotiated,
>>>>>
>>>>>>
>>>>>> I'll patch that in and test it out.
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>>
>>>>>> On Thursday, September 19, 2019 at 9:58:49 PM UTC-5, Waldek Kozaczuk
>>>>>> wrote:
>>>>>>>
>>>>>>> This patch seems to do the job:
>>>>>>>
>>>>>>> diff --git a/drivers/virtio-net.cc b/drivers/virtio-net.cc
>>>>>>> index e78fb3af..fe5f1ae0 100644
>>>>>>> --- a/drivers/virtio-net.cc
>>>>>>> +++ b/drivers/virtio-net.cc
>>>>>>> @@ -375,6 +375,8 @@ void net::read_config()
>>>>>>> net_i("Features: %s=%d,%s=%d", "Host TSO ECN", _host_tso_ecn,
>>>>>>> "CSUM", _csum);
>>>>>>> net_i("Features: %s=%d,%s=%d", "Guest_csum", _guest_csum,
>>>>>>> "guest tso4", _guest_tso4);
>>>>>>> net_i("Features: %s=%d", "host tso4", _host_tso4);
>>>>>>> +
>>>>>>> + printf("VIRTIO_NET_F_MRG_RXBUF: %d\n", _mergeable_bufs);
>>>>>>> }
>>>>>>>
>>>>>>> /**
>>>>>>> @@ -591,16 +593,19 @@ void net::fill_rx_ring()
>>>>>>> vring* vq = _rxq.vqueue;
>>>>>>>
>>>>>>> while (vq->avail_ring_not_empty()) {
>>>>>>> - auto page = memory::alloc_page();
>>>>>>> + //auto page = memory::alloc_page();
>>>>>>> + auto page = malloc(16 * memory::page_size);
>>>>>>>
>>>>>>> vq->init_sg();
>>>>>>> - vq->add_in_sg(page, memory::page_size);
>>>>>>> + vq->add_in_sg(page, memory::page_size * 16);
>>>>>>> if (!vq->add_buf(page)) {
>>>>>>> - memory::free_page(page);
>>>>>>> + //memory::free_page(page);
>>>>>>> + free(page);
>>>>>>> break;
>>>>>>> }
>>>>>>> added++;
>>>>>>> }
>>>>>>> + printf("net: Allocated %d pages\n", added * 16);
>>>>>>>
>>>>>>> trace_virtio_net_fill_rx_ring_added(_ifn->if_index, added);
>>>>>>>
>>>>>>>
>>>>>>> But for sure it is just a hack. I am not sure if we should actually
>>>>>>> allocate 16 pages in one shot (which I am doing here) vs create single
>>>>>>> chained buffer made of 16 pages. Not sure how we should extract data if
>>>>>>> chained.
>>>>>>>
>>>>>>> I have also found this (based on a comment in firecracker code) -
>>>>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=753630. As
>>>>>>> you can see VIRTIO_NET_F_MRG_RXBUF is much more memory efficient and
>>>>>>> flexible which is what QEMU implements.
>>>>>>>
>>>>>>> I am interested in what others think how we should handle this
>>>>>>> properly.
>>>>>>>
>>>>>>> Either way I think it would not hurt creating an issue against
>>>>>>> Firecracker to ask supporting VIRTIO_NET_F_MRG_RXBUF.
>>>>>>>
>>>>>>> Waldek
>>>>>>>
>>>>>>> On Thursday, September 19, 2019 at 6:59:22 PM UTC-4, Henrique
>>>>>>> Fingler wrote:
>>>>>>>>
>>>>>>>> I'm trying to check if it works on qemu, but scripts/run and
>>>>>>>> capstan run set the network differently than Firecracker's script.
>>>>>>>> With the regular user networking (no "-n") it works. When I try
>>>>>>>> running it with with "-n -b br0" or just "-n" the execution hangs
>>>>>>>> after
>>>>>>>> printing OSv version.
>>>>>>>>
>>>>>>>> I'm trying to manually hack the allocation of a single but larger
>>>>>>>> size for the receive queue and disabling VIRTIO_NET_F_MRG_RXBUF on
>>>>>>>> the driver just to check what Firecracker does, but it seems that
>>>>>>>> during
>>>>>>>> compilation a qemu instance of the unikernel is launched. Is this a
>>>>>>>> test?
>>>>>>>> Can this be disabled?
>>>>>>>>
>>>>>>>> Also, is there a way to find which hypervisor OSv is running on
>>>>>>>> top of? This would help switching between feature sets in virtio-net.
>>>>>>>>
>>>>>>>> Thanks!
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thursday, September 19, 2019 at 11:02:53 AM UTC-5, Waldek
>>>>>>>> Kozaczuk wrote:
>>>>>>>>>
>>>>>>>>> Most likely it is a bug on OSv side. It could be in the virtio-net
>>>>>>>>> features negotiation logic -
>>>>>>>>> https://github.com/cloudius-systems/osv/blob/master/drivers/virtio-net.cc#L351-L378
>>>>>>>>> or
>>>>>>>>> https://github.com/cloudius-systems/osv/blob/master/drivers/virtio-net.cc#L283-L297
>>>>>>>>> .
>>>>>>>>>
>>>>>>>>> I also saw this comment in firecracker code -
>>>>>>>>> https://github.com/firecracker-microvm/firecracker/blob/master/devices/src/virtio/net.rs#L153-L154
>>>>>>>>> -
>>>>>>>>> which seems to indicate that VIRTIO_NET_F_MRG_RXBUF is NOT
>>>>>>>>> supported by firecracker -
>>>>>>>>> https://github.com/firecracker-microvm/firecracker/blob/f123988affa8f25683a7c26f7a48dd76e839a796/devices/src/virtio/net.rs#L705-L711
>>>>>>>>> ?
>>>>>>>>>
>>>>>>>>> This section of VirtIO spec would apply then:
>>>>>>>>>
>>>>>>>>> "5.1.6.3.1 Driver Requirements: Setting Up Receive Buffers
>>>>>>>>>
>>>>>>>>> - If VIRTIO_NET_F_MRG_RXBUF is not negotiated:
>>>>>>>>> - If VIRTIO_NET_F_GUEST_TSO4, VIRTIO_NET_F_GUEST_TSO6 or
>>>>>>>>> VIRTIO_NET_F_GUEST_UFO are negotiated, the driver SHOULD
>>>>>>>>> populate the
>>>>>>>>> receive queue(s) with buffers of at least 65562 bytes.
>>>>>>>>> - Otherwise, the driver SHOULD populate the receive
>>>>>>>>> queue(s) with buffers of at least 1526 bytes.
>>>>>>>>> - If VIRTIO_NET_F_MRG_RXBUF is negotiated, each buffer MUST be
>>>>>>>>> at greater than the size of the struct virtio_net_hdr."
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> This makes me think that our receive buffers are only 1 page (4096
>>>>>>>>> bytes) large so whenever Firecracker tries to send a buffer bigger
>>>>>>>>> than
>>>>>>>>> that OSv bounces. Think this OSv code applies -
>>>>>>>>> https://github.com/cloudius-systems/osv/blob/master/drivers/virtio-net.cc#L587-L609.
>>>>>>>>>
>>>>>>>>> It seems the virtio ring buffers are alway 1 page big - see
>>>>>>>>> alloc_page
>>>>>>>>> call.
>>>>>>>>>
>>>>>>>>> So maybe on OSv side we need to allow for bigger buffers (64K)
>>>>>>>>> when VIRTIO_NET_F_MRG_RXBUF is off which would require changes to
>>>>>>>>> drivers/virtio-vring.cc. I wonder if on QEMU this feature is on
>>>>>>>>> and that is why we never see this issue of QEMU, do we? It would be
>>>>>>>>> nice to
>>>>>>>>> run same Python program in qemu and see if VIRTIO_NET_F_MRG_RXBUF
>>>>>>>>> is on or off.
>>>>>>>>>
>>>>>>>>> This is all my speculation and I might be off so maybe others can
>>>>>>>>> shed more light on it.
>>>>>>>>>
>>>>>>>>> Waldek
>>>>>>>>>
>>>>>>>>> On Thursday, September 19, 2019 at 12:09:19 AM UTC-4, Henrique
>>>>>>>>> Fingler wrote:
>>>>>>>>>>
>>>>>>>>>> How do I go about disabling GSO?
>>>>>>>>>> I think I found how to disable TSO (diff below), but I can't
>>>>>>>>>> find where to disable GSO. Disabling just TSO didn't fix it.
>>>>>>>>>>
>>>>>>>>>> The loop where Firecracker gets stuck (fn rx_single_frame) tries
>>>>>>>>>> to write an entire frame (7318 bytes) and it notices it doesn't fit
>>>>>>>>>> into
>>>>>>>>>> all the descriptors of the guest.
>>>>>>>>>> It seems that if it fails to write the entire frame, it marks
>>>>>>>>>> descriptors as used, but retries to deliver the whole frame again.
>>>>>>>>>> Maybe
>>>>>>>>>> the OSv buffer isn't big enough and FC just loops forever?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> virtio-net.cc:
>>>>>>>>>>
>>>>>>>>>> | (1 << VIRTIO_NET_F_STATUS) \
>>>>>>>>>> | (1 << VIRTIO_NET_F_CSUM) \
>>>>>>>>>> | (1 << VIRTIO_NET_F_GUEST_CSUM) \
>>>>>>>>>> - | (1 << VIRTIO_NET_F_GUEST_TSO4) \
>>>>>>>>>> + | (0 << VIRTIO_NET_F_GUEST_TSO4) \
>>>>>>>>>> | (1 << VIRTIO_NET_F_HOST_ECN) \
>>>>>>>>>> - | (1 << VIRTIO_NET_F_HOST_TSO4) \
>>>>>>>>>> + | (0 << VIRTIO_NET_F_HOST_TSO4) \
>>>>>>>>>> | (1 << VIRTIO_NET_F_GUEST_ECN)
>>>>>>>>>> | (1 << VIRTIO_NET_F_GUEST_UFO)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thanks!
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Wednesday, September 18, 2019 at 8:23:21 PM UTC-5, Asias He
>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Sep 19, 2019 at 7:06 AM Henrique Fingler <
>>>>>>>>>>> [email protected]> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> First of all, thank you for being active and helping out users!
>>>>>>>>>>>>
>>>>>>>>>>>> Here's my setup: I'm building a python3 image, with a script
>>>>>>>>>>>> that does
>>>>>>>>>>>>
>>>>>>>>>>>> * response = urllib.request.urlopen("http://<a 1mb file>")*
>>>>>>>>>>>>
>>>>>>>>>>>> The execution just hangs for a few seconds, then a storm of
>>>>>>>>>>>> warnings from Firecracker show up:
>>>>>>>>>>>>
>>>>>>>>>>>> <A lot of the same warning>
>>>>>>>>>>>> 2019-09-18T17:50:36.841517975
>>>>>>>>>>>> [anonymous-instance:WARN:devices/src/virtio/net.rs:257]
>>>>>>>>>>>> Receiving buffer is too small to hold frame of current size
>>>>>>>>>>>> 2019-09-18T17:50:36.841529410
>>>>>>>>>>>> [anonymous-instance:WARN:devices/src/virtio/net.rs:257]
>>>>>>>>>>>> Receiving buffer is too small to hold frame of current size
>>>>>>>>>>>> 2019-09-18T17:50:36.841569665
>>>>>>>>>>>> [anonymous-instance:WARN:devices/src/virtio/net.rs:257]
>>>>>>>>>>>> Receiving buffer is too small to hold frame of current size
>>>>>>>>>>>> 2019-09-18T17:50:36.841584097
>>>>>>>>>>>> [anonymous-instance:WARN:devices/src/virtio/net.rs:257]
>>>>>>>>>>>> Receiving buffer is too small to hold frame of current size
>>>>>>>>>>>> 2019-09-18T17:50:36.841656060
>>>>>>>>>>>> [anonymous-instance:WARN:devices/src/virtio/net.rs:257]
>>>>>>>>>>>> Receiving buffer is too small to hold frame of current size
>>>>>>>>>>>>
>>>>>>>>>>>> This is coming from here:
>>>>>>>>>>>> https://github.com/firecracker-microvm/firecracker/blob/master/devices/src/virtio/net.rs
>>>>>>>>>>>>
>>>>>>>>>>>> If the file is smaller, let's say 256B, it works fine
>>>>>>>>>>>>
>>>>>>>>>>>> Could this be a bug in the virtio implementation of OSv or is
>>>>>>>>>>>> it a Firecraker thing?
>>>>>>>>>>>> I'll start to investigate the issue. I'm asking because you
>>>>>>>>>>>> might have seen this problem.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Try disable gso/tso in osv viriot-net driver.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks!
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> You received this message because you are subscribed to the
>>>>>>>>>>>> Google Groups "OSv Development" group.
>>>>>>>>>>>> To unsubscribe from this group and stop receiving emails from
>>>>>>>>>>>> it, send an email to [email protected].
>>>>>>>>>>>> To view this discussion on the web visit
>>>>>>>>>>>> https://groups.google.com/d/msgid/osv-dev/965f0cad-d074-4b18-b998-ffe5777851a2%40googlegroups.com
>>>>>>>>>>>>
>>>>>>>>>>>> <https://groups.google.com/d/msgid/osv-dev/965f0cad-d074-4b18-b998-ffe5777851a2%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>>>>>>>>> .
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Asias
>>>>>>>>>>>
>>>>>>>>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "OSv Development" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to [email protected].
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/osv-dev/64ae1bcf-9506-4a52-8ca6-4b0921981f9f%40googlegroups.com
>>>
>>> <https://groups.google.com/d/msgid/osv-dev/64ae1bcf-9506-4a52-8ca6-4b0921981f9f%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "OSv Development" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/osv-dev/InlSKnJAfMQ/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> [email protected].
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/osv-dev/CA%2B3q14xYSikYznw1iCkxtO0%2BRqmcrUirShVU-e1_Pwpp3Zd1yw%40mail.gmail.com
>>
>> <https://groups.google.com/d/msgid/osv-dev/CA%2B3q14xYSikYznw1iCkxtO0%2BRqmcrUirShVU-e1_Pwpp3Zd1yw%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>>
--
You received this message because you are subscribed to the Google Groups "OSv
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/osv-dev/cf2a55ad-1821-495c-866b-1756ad966891%40googlegroups.com.
