[dpdk-dev] [PATCH] Request for comments on ixgbe TSO support

jigsaw jigsaw at gmail.com
Fri Oct 4 21:10:33 CEST 2013


Hi Stephen,

Thanks for showing a bigger picture.

GSO is quite big implementation, that I think it won't be easily
ported to DPDK. The mbuf needs to be equipped with many fields from
skb to be able to deal with GSO.
Do you have the plan to port GSO to DPDK, or you would like to keep
GSO in scope of virtio?

Regarding checksum flags, actually I was also thinking of extending
ol_flags but then I gave it up coz I was worried about the size of
mbuf.
My current patch has to push some work to user, due to the fact that
mbuf delivers too few info (such as L2 and L3 protocol details).

Besides, as you mentioned, the ixgbe driver doesn't leverage the
hardware receive checksum offloading at all. And if this is to be
supported, the checksum flag need further extension.
(On the other hand, TSO doesn't care about receive checksum offloading).
Again, do you have plans to extend cksum flags so that virio feels
more comfortable with DPDK?

Hi Venky,

I can either make the commit now as is, or wait till the cksum flags
extension is in place. If Stephen (or somebody else) has the plan for
better support for cksum offloading or GSO, it is perhaps better to
implement TSO on top of that.

BTW, I have another small question. Current TSO patch offloads the
TCP/IP pseudo cksum work to user. Do you think DPDK could provide some
utility functions for TCP/IPv4/IPv6 pseudo cksum calculation and
updating?

thx &
rgds,
-Qinglai


On Fri, Oct 4, 2013 at 9:38 PM, Venkatesan, Venky
<venky.venkatesan at intel.com> wrote:
> Stephen,
>
> Agree on the checksum flag definition. I'm presuming that we should do this on the L3 and L4 checksums separately (that ol_flags field is another one that needs extension in the mbuf).
>
> Regards,
> -Venky
>
>
> -----Original Message-----
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Stephen Hemminger
> Sent: Friday, October 04, 2013 11:23 AM
> To: jigsaw
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] Request for comments on ixgbe TSO support
>
> On Fri, 4 Oct 2013 20:54:31 +0300
> jigsaw <jigsaw at gmail.com> wrote:
>
>> Hi Stephen,
>>
>>
>> >>This will work for local generated packets but overlapping existing field won't work well for forwarding.
>> So adding a new mss field in mbuf could be the way out? or I
>> misunderstand something.
>>
>> >> What we want to be able to do is to take offload (jumbo) packets in
>> >> with from virtio
>> Sorry I don't understand why TSO is connected to virtio. Could you
>> give more details here?
>> Are you suggesting this TSO patch overlaps your work, or it should be
>> based on your work?
>
> I am working on a better virtio driver. Already have lots more features working, and doing better offload support is planned.
>
> TSO is a subset of the more generic segment offload (GSO) on Linux.
> With virtio is possible to receive GSO packets as well as send them.
> This feature is negotiated between guest and host.
>
> The idea is that between guests they can exchange jumbo (64K) packets even with a smaller MTU. This helps in many ways. One example is only a single route lookup is needed.
>
> Another issue is that the current DPDK model of offload flags for checksum is problematic.
> It matches what is available in Intel hardware and is not easily generalizable to other devices.
>
> Current DPDK flag is checksum bad. I would like to change it to checksum known good. Then drivers which dont' do checksum would leave it 0, but if receive checksum is known good set it to 1.  Basically 1 means known good, and
> 0 means unknown (or bad).  Higher level software can then do sw checksum if necessary.


More information about the dev mailing list