On Tue, Dec 24, 2013 at 04:35:57PM +0900, Simon Horman wrote: > On Tue, Dec 17, 2013 at 05:08:35PM -0800, Ben Pfaff wrote: > > On Mon, Dec 16, 2013 at 05:57:52PM +0900, Simon Horman wrote: > > > If VLAN acceleration is used when the kernel receives a packet > > > then the outer-most VLAN tag will not be present in the packet > > > when it is received by netdev-linux. Rather, it will be present > > > in auxdata. > > > > > > This patch uses recvmsg() instead of recv() to read auxdata for > > > each packet and if the vlan_tid is set then it is added to the packet. > > > > > > Adding the vlan_tid makes use of headroom available > > > in the buffer parameter of rx_recv. > > > > > > Signed-off-by: Simon Horman <ho...@verge.net.au> > > > > This patch should be Linux-specific, why does it update netdev-bsd? > > > > I think we should add a comment to netdev_rx_recv() explaining how the > > tailroom in the buffer may get used (you might need 4 bytes more > > tailroom than the actual MTU, and you might get 4 bytes of extra > > headroom in the result). > > Sure, how about this? > > /* Attempts to receive a packet from 'rx' into 'buffer'. > * If successful, returns 0 and increments the 'size' field of 'buffer' > * by the number of bytes in the received packet, otherwise a positive > * errno value. Returns EAGAIN immediately if no packet is ready to > * be received. > * > * Must return EMSGSIZE, and discard the packet, if the received packet > * is longer than the tailroom of 'buffer'. > * > * Implementations may make use of VLAN_HEADER_LEN bytes of tailroom to > * add a VLAN header which is obtained out-of-band to the packet. If > * this occurs then VLAN_HEADER_LEN bytes of tailroom will no longer be > * available for the packet, otherwise it may be used for the packet > * itself. > * > * It is advised that the tailroom of 'buffer' should be > * VLAN_HEADER_LEN bytes longer than the MTU to allow space for an > * out-of-band VLAN header to be added to the packet. > * > * Specify NULL if this */
That's OK except for the last sentence fragment. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
