Remove last_size check.

[clopez]

• The variable last_size is not used in any part of the code other than
  this two lines. This seems to have been added for debug purposes and
  was left there.
• This code starts triggering on a kernel >= 3.14 (Ubuntu 14.04 uses
  3.13, so this went unnoticed). It causes a lot of flood because it
  triggers constantly.
• Example of the output from snabswitch when running same_vlan.ports
  with both VMs running Kernel 3.14.23 and running an iperf test
  (MTU 1500) between both VMs:

      size=  2036
      size=  1524
      size=  2036
      size=  1524
      size=  2036
      size=  1524
      [ .... repeated ad-infinitum ]

• I have bisected the Linux kernel, the commit that causes this print to
  trigger is fb51879dbceab9c40a39018d5322451691909e15 (merged on 3.14)
  https://git.kernel.org/linus/fb51879

[clopez]

CC'ing @N-Nikolaev (the author of that lines)

[ghost]

If this is causing the bad iperf results we should definitely remove it out of the data path.
One question though - can we keep the code commented or "debug" only?

[clopez]

This causes bad results when running a kernel >= 3.14 inside the VMs because of the print flooding.
But is not causing the bad iperf results with MTU=9000 observed in PR #312

I will update the PR

[clopez]

Ok. Seems that I'm still not mastering the github workflow. I'm not sure how to rewrite a pull request branch...

I have opened a new PR #324 to add a new command line argument to snabswitch to enable a debug mode, and changed the print to only happen when that debug mode is enabled

[lukego]

Great catch!

I really wish the kernel would consistently give us buffers of at least 2060 bytes. Then we could DMA 2048 bytes and still have space for the 12-bytes of Virtio metadata. There are many factors that make it hard to do zero-copy with Virtio (i.e. hardware DMA directly into the buffers obtained over Virtio) and it would be wonderful to interest the community in making this work smoother.