On Wed, Sep 18, 2019 at 08:04:18PM -0600, Subash Abhinov Kasiviswanathan wrote: > On 2019-09-18 10:10, Willem de Bruijn wrote: > > On Wed, Sep 18, 2019 at 3:25 AM Steffen Klassert > > <steffen.klass...@secunet.com> wrote: > > > > > > This adds a new NETIF_F_GRO_LIST feature flag. I will be used > > > to configure listfyed GRO what will be implemented with some > > > followup paches. > > > > This should probably simultaneously introduce SKB_GSO_FRAGLIST as well > > as a BUILD_BUG_ON in net_gso_ok. > > > > Please also in the commit describe the constraints of skbs that have > > this type. If I'm not mistaken, an skb with either gso_size linear > > data or one gso_sized frag, followed by a frag_list of the same. With > > the exception of the last frag_list member, whose mss may be less than > > gso_size. This will help when reasoning about all the types of skbs we > > may see at segmentation, as we recently had to do [1] > > > > Would it be preferrable to allow any size skbs for the listification.
We currently require a single gso_size because we adjust uh->len on the head skb to the full size to do correct memory accounting on the local input path. That is going to be restored with the gso_size on segmentation. > Since the original skbs are being restored, single gso_size shoudln't > be a constraint here. It might be possible to allow any sized skbs with some extra work, though.
