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? _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
