On Thu, Apr 19, 2012 at 6:47 PM, Simon Horman <ho...@verge.net.au> wrote: > On Thu, Apr 19, 2012 at 05:55:28PM -0700, Jesse Gross wrote: >> On Thu, Apr 19, 2012 at 5:13 PM, Simon Horman <ho...@verge.net.au> wrote: >> > On Thu, Apr 19, 2012 at 01:29:08PM -0700, Jesse Gross wrote: >> >> On Wed, Apr 18, 2012 at 9:50 PM, Simon Horman <ho...@verge.net.au> wrote: >> >> > It seems to me that some changes are needed to the tunneling core code, >> >> > in particular handle_offloads(), to allow GSO skbs to be passed >> >> > unsegmented to STT. Perhaps a new mutable->flags flag is in order? >> >> >> >> I agree that there definitely needs to be additional information given >> >> to the tunneling core to enable it to decide whether or not to emulate >> >> offloads. However, I think the information belongs in tnl_ops instead >> >> of mutable->flags since it is shared by all tunnels of a given type. >> > >> > Thanks, I will look into that. >> > >> > At this point I am thinking of a single flag to indicate that >> > the protocol handler is able to handle GSO skbs. I'll see about preparing >> > a patch to implement that. But perhaps a single flag is insufficient >> > for some cases? >> >> I think it needs to be a little more sophisticated that that. In the >> cases that where you currently drop the packet due to being >> incompatible with STT (such as an extra level of vlan tag, L4 offset >> too large, etc.) we should do software segmentation to avoid the need >> to offload over STT. Also not all types of GSO types are supported >> over STT (such as FCoE or future ones that don't exist today). >> Probably a function to evaluate a packet for offloading is more >> appropriate. > > Ok, so an extra callback that may optionally be implemented by a tunnelling > protocol?
Yes, that's what I was thinking. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
