> -----Original Message----- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Monday, October 20, 2014 3:51 PM > To: Walukiewicz, Miroslaw > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH] pmd: Add generic support for TCP TSO > (Transmit Segmentation Offload) > > 2014-10-20 12:45, Walukiewicz, Miroslaw: > > > > /* fields to support TX offloads */ > > > > - union { > > > > - uint16_t l2_l3_len; /**< combined l2/l3 lengths as > > > > single var > > > */ > > > > - struct { > > > > - uint16_t l3_len:9; /**< L3 (IP) Header > > > > Length. */ > > > > - uint16_t l2_len:7; /**< L2 (MAC) Header > > > > Length. > > > */ > > > > + /* two bytes - l2/l3 len for compatibility (endian issues) > > > > + * two bytes - reseved for alignment > > > > + * two bytes - l4 len (TCP/UDP) header len > > > > + * two bytes - TCP tso segment size > > > > + */ > > > > + struct { > > > > + union { > > > > + uint16_t l2_l3_len; /**< combined l2/l3 len */ > > > > + struct { > > > > + uint16_t l3_len:9; /**< L3 (IP) Header > > > > */ > > > > + uint16_t l2_len:7; /**< L2 (MAC) Header > > > > */ > > > > + }; > > > > }; > > > > > > Why nesting these fields in an anonymous structure? > > > > I want to keep a source compatibility with non-TSO applications using that > > field for example IP checksum computing by NIC. > > Keeping this structure anonymous I do not require changes in old > > applications that do not need TSO support. > > > > The second argument is that in original patch extending the rte_mbuf to > 128 > > bytes made by Bruce the author made this structure anonymous and I > follow > > this assumption too. > > Excuse me, maybe I missed something, but I still don't understand why you > are > embedding the union into a struct?
You are right. It has no sense. Let me send a new version of the patch with new structure definition and better description > > -- > Thomas
