[dpdk-dev] [PATCH v5] doc: add GRO API limitations in prog_guide

[Morten Brørup]

> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Ananyev, Konstantin
> > From: Stephen Hemminger [mailto:stephen at networkplumber.org]
> >
> > O        be merged.
> > > +
> > > +GRO Library Limitations
> > > +-----------------------
> > > +
> > > +- GRO library uses the values of MBUF->l2_len/l3_len/l4_len/
> > > +  outer_l2_len/outer_l3_len to get protocol headers for the
> > > +  input packet, rather than parsing the packet header. Therefore,
> > > +  before call GRO APIs to merge packets, user applications
> > > +  must set MBUF->l2_len/l3_len/l4_len/outer_l2_len/outer_l3_len
> > > +  to the same values as the protocol headers of the packet.
> > > +
> >
> > Since these length values are critical to other functionality
> > why not require all poll mode drivers to set them.
> 
> Most of current HW doesn't provide that functionality,
> so RX function would need to parse (touch) packet data.

True... In an application where the first process step is to receive the packet from the PMD and put it directly into the appropriate queue (or drops it) solely based on information provided in the "RX part" of the MBUF, two cache misses can be avoided - reading the header in the packet data and writing the "TX part" of the mbuf.

This is a key selling point for NIC hardware with the ability to perform classification, such as the Flow Director feature, so it can efficiently identify and discard packets related to DDOS attacks, as an example.

> From other side not every rx_burst() consumer does use GRO library.
> 

Nonetheless, many applications need to touch the packet header on ingress for classification purposes - either to identify a flow or to identify the attributes used for routing and QoS classification.

I expect that validating packet headers (i.e. identifying malformed packets) somewhere early on the ingress fast path is a very common use case, which is why I on another thread suggested extending rte_net_get_ptype() to check packet validity and building a bulk function on top of that to set the MBUF->l2_len/l3_len... fields, so they are ready for GRO, Fragment Reassembly and other ingress path libraries requiring this information: https://mails.dpdk.org/archives/dev/2019-January/122701.html

> >
> > Many poll mode drivers call rte_net_get_ptype() on the received
> > mbuf and it already handles setting this.
> >
> > One could argue that GRO should just log and die if it
> > gets malformed data.

This would be a good principle! If preconditions are not met, it is a bug and should be treated as such. As I mentioned before, this specific function is not taking foreign input; the application is in full control of passing garbage or not to this function.


Med venlig hilsen / kind regards
- Morten Brørup