On Mon, Feb 1, 2021 at 3:08 AM Loic Poulain <loic.poul...@linaro.org> wrote:
>
> Hi Jakub, Willem,
>
> On Sat, 30 Jan 2021 at 02:01, Jakub Kicinski <k...@kernel.org> wrote:
> >
> > On Mon, 25 Jan 2021 16:45:57 +0100 Loic Poulain wrote:
> > > When device side MTU is larger than host side MRU, the packets
> > > (typically rmnet packets) are split over multiple MHI transfers.
> > > In that case, fragments must be re-aggregated to recover the packet
> > > before forwarding to upper layer.
> > >
> > > A fragmented packet result in -EOVERFLOW MHI transaction status for
> > > each of its fragments, except the final one. Such transfer was
> > > previoulsy considered as error and fragments were simply dropped.
> > >
> > > This patch implements the aggregation mechanism allowing to recover
> > > the initial packet. It also prints a warning (once) since this behavior
> > > usually comes from a misconfiguration of the device (modem).
> > >
> > > Signed-off-by: Loic Poulain <loic.poul...@linaro.org>
> >
> > > +static struct sk_buff *mhi_net_skb_append(struct mhi_device *mhi_dev,
> > > + struct sk_buff *skb1,
> > > + struct sk_buff *skb2)
> > > +{
> > > + struct sk_buff *new_skb;
> > > +
> > > + /* This is the first fragment */
> > > + if (!skb1)
> > > + return skb2;
> > > +
> > > + /* Expand packet */
> > > + new_skb = skb_copy_expand(skb1, 0, skb2->len, GFP_ATOMIC);
> > > + dev_kfree_skb_any(skb1);
> > > + if (!new_skb)
> > > + return skb2;
> >
> > I don't get it, if you failed to grow the skb you'll return the next
> > fragment to the caller? So the frame just lost all of its data up to
> > where skb2 started? The entire fragment "train" should probably be
> > dropped at this point.
>
> Right, there is no point in keeping the partial packet in that case.
>
> >
> > I think you can just hang the skbs off skb_shinfo(p)->frag_list.
> >
> > Willem - is it legal to feed frag_listed skbs into netif_rx()?
>
> In QMAP case, the packets will be forwarded to rmnet link, which works
> with linear skb (no NETIF_F_SG), does the linearization will be
> properly performed by the net core, in the same way as for xmit path?
What is this path to rmnet, if not the usual xmit path / validate_xmit_skb?
