netmap wishlist

[Eggert, Lars]

Hi,

On 2014-9-12, at 9:31, Luigi Rizzo <rizzo at iet.unipi.it> wrote:
> there is something already available/in progress for some of the above,
> but here are my thoughts on the various subjects:
> 
> - netmap is designed to work with large frames, by setting the buffer
>   size to something suitable (using a sysctl).
...
>     The downside is some waste on buffers (they are fixed size so having
>   to allocate say 16K for a 64 byte frame is a bit annoying).

that's OK for what I'm doing.

> - checksums offloading can be added trivially in the *_txsync(),
>   once again on a per-nic basis.
>   Problem is, is we start adding per-packet features (say, checksums,
>   scatter-gather I/O, segmentation) in the inner loop of *_txsync()
>   we are going to lose some performance for high rate applications.

What about making these things compile-time options? I totally see that if you want to use netmap for fast switching, you wouldn't want these. But if you use netmap for operating on IP and transport protocol packets, they become really essential. (Esp. at 40G - which reminds me that I forgot to add netmap support for the ixl driver to the wishlist...)

> - the VALE switch has support for segmentation and checksum avoidance.
>   Clients can register as virtio-net capable: in this case the port will
>   accept/deliver large segments across that port, and do segmentation and
>   checksum as required for ports that are not virtio-net enabled
>   (e.g. physical NICs attached to the same VALE switch).
>   This was developed earlier this year by Vincenzo Maffione.

I may look into this. I'm unclear if adding a VALE layer into the system just to get this feature would be wort it in terms of performance.

>   We could probably leverage this code to work also on top of NICs
>   connected through netmap, e.g. programming the NIC to use its own
>   native offloading, but i am skeptical about the usefulness and
>   concerned about the potential performance loss in *_txsync().

I totally see that, but maybe a compile-time option would work. There are several distinct use cases for netmap at the moment, and it's unlikely that the same system would need to support several of them, so compile-time specialization may be sufficient here.

> - Stefano Garzarella has some code to do software GSO (this is for FreeBSD,
>   linux already has something similar), which will be presented at
>   EuroBSDCon later this month in Sofia. This should address the
>   segmentation issue on the host stack.

Nice, I will take a look.

> - on the receive side, both FreeBSD and Linux have an efficient
>   RLO software fallback in case the NIC does not support it
>   natively, i think we do not need this at the NIC/switch level.

OK, I need to look into this.

Oh, and my list was prioritized - I think the checksum offload would be the real winner when dealing munging IP and transport packets.

Thanks,
Lars
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 273 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/freebsd-net/attachments/20140912/a196c42c/attachment.sig>