You can always pretend the MTU is smaller than it actually is and do segmenting yourself, however this defeats the purpose of Large Segment Offload (LSO), which is a key HW offload capability of most modern I/O interfaces. With LSO the application can send arbitrary sized packets (up to at least 64KB) and the HW divides them into MTU-sized segments with appropriate headers for each segment (e.g., ensuring IPv4 ID uniqueness, proper TCP seq numbers, etc.) as part of TX processing.
On the RX side, Large Receive Offload (LRO) does the inverse, taking an oversized arriving packet and chopping it up into MTU-sized packets, often doing other things like header splitting for better cache utilization (packet headers have their own separate receive buffers that are physically disjoint from packet payload) since the network stacks are often most concerned with headers rather than payload. Do we know what the DPDK use case is for introducing this API? On Fri, Jan 29, 2016 at 10:28 AM, Zoltan Kiss <zoltan.k...@linaro.org> wrote: > > > On 29/01/16 08:26, Savolainen, Petri (Nokia - FI/Espoo) wrote: > >> If two applications share a link (pktio), >> > > A diverging question, but: how does that work? Who calls > odp_init_global()? Who calls pktio_open? And how do they share the same > pktio? > > > both can send up to MTU sized > >> frames … and if one of them wants send less than MTU sized frames, it’s >> free to do that (without forcing the other app to the same limit). From >> ODP API point of view, MTU is the limit of the local transmit buffer. >> Whereas from IP stack point of view (to avoid fragmenting) it could be >> the minimum of: local tx buf (== ODP MTU), gateway rx/tx buf and >> destination rx buf sizes. >> > > The reason I asked because although OVS follows the idea Bill explained, > and handles the MTU as a read-only information (with the kernel module > datapath you can send it with ifconfig), but there is an upcoming patch to > implement a dpdk-mtu parameter, because in case of DPDK you can only set > that through the application (except I think if you use KNI) > > Regards, > > Zoli > > >> -Petri >> >> *From:*lng-odp [mailto:lng-odp-boun...@lists.linaro.org] *On Behalf Of >> *EXT Bill Fischofer >> *Sent:* Thursday, January 28, 2016 7:25 PM >> *To:* Mike Holmes >> *Cc:* lng-odp >> *Subject:* Re: [lng-odp] Setting MTU >> >> The short answer is that MTU is not an application parameter but a >> system configuration parameter. As such it is the domain of the >> control/management plane rather than the data plane. The data plane >> simply uses the MTU that has been configured elsewhere. Applications >> use higher-level segmenting like the TCP MSS that is negotiated for each >> connection. >> >> As a practical matter, at 10Gb and above link speeds (what ODP is >> designed for), all interfaces should be running with 9K jumbo frames >> anyway. MTU is something of a legacy from the early days of networking >> where primitive low-speed devices had extremely limited buffering >> capacities, necessitating these tiny MTU values. They are really not >> relevant to 21st-century data plane processing. >> >> On Thu, Jan 28, 2016 at 9:06 AM, Mike Holmes <mike.hol...@linaro.org >> <mailto:mike.hol...@linaro.org>> wrote: >> >> commit 45598fea1a8a64ab49e191224784188382fbd466 >> >> Author: Petri Savolainen <petri.savolai...@nokia.com >> <mailto:petri.savolai...@nokia.com>> >> >> Date: Thu Jan 21 11:39:29 2016 +0200 >> >> api: pktio: remove odp_pktio_set_mtu >> >> Not all hardware can change MTU size from ODP application. >> >> Reviewed-by: Petri Savolainen <petri.savolai...@linaro.org >> <mailto:petri.savolai...@linaro.org>> >> >> Signed-off-by: Maxim Uvarov <maxim.uva...@linaro.org >> <mailto:maxim.uva...@linaro.org>> >> >> On 28 January 2016 at 08:30, Zoltan Kiss <zoltan.k...@linaro.org >> <mailto:zoltan.k...@linaro.org>> wrote: >> >> Hi, >> >> Is there a specific reason why we don't have an MTU setting API, >> but only one to query it? >> >> Zoli >> _______________________________________________ >> lng-odp mailing list >> lng-odp@lists.linaro.org <mailto:lng-odp@lists.linaro.org> >> https://lists.linaro.org/mailman/listinfo/lng-odp >> >> >> >> -- >> >> Mike Holmes >> >> Technical Manager - Linaro Networking Group >> >> Linaro.org <http://www.linaro.org/>***│ *Open source software for >> ARM SoCs >> >> "Work should be fun and collborative, the rest follows" >> >> >> _______________________________________________ >> lng-odp mailing list >> lng-odp@lists.linaro.org <mailto:lng-odp@lists.linaro.org> >> https://lists.linaro.org/mailman/listinfo/lng-odp >> >> >> >> _______________________________________________ >> lng-odp mailing list >> lng-odp@lists.linaro.org >> https://lists.linaro.org/mailman/listinfo/lng-odp >> >>
_______________________________________________ lng-odp mailing list lng-odp@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lng-odp
