From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52239) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aoQpi-0001jH-L4 for qemu-devel@nongnu.org; Fri, 08 Apr 2016 03:27:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aoQpf-0005fZ-Fj for qemu-devel@nongnu.org; Fri, 08 Apr 2016 03:27:58 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39426) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aoQpf-0005fL-82 for qemu-devel@nongnu.org; Fri, 08 Apr 2016 03:27:55 -0400 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id E731785366 for ; Fri, 8 Apr 2016 07:27:53 +0000 (UTC) References: <1459711556-10273-1-git-send-email-wexu@redhat.com> <1459711556-10273-4-git-send-email-wexu@redhat.com> <570327E7.7070908@redhat.com> <57075874.8060903@redhat.com> From: Jason Wang Message-ID: <57075D76.2000306@redhat.com> Date: Fri, 8 Apr 2016 15:27:50 +0800 MIME-Version: 1.0 In-Reply-To: <57075874.8060903@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [ RFC Patch v4 3/3] virtio-net rsc: support coalescing ipv6 tcp traffic List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Wei Xu , qemu-devel@nongnu.org On 04/08/2016 03:06 PM, Wei Xu wrote: > > > On 2016=E5=B9=B404=E6=9C=8805=E6=97=A5 10:50, Jason Wang wrote: >> >> On 04/04/2016 03:25 AM, wexu@redhat.com wrote: >>> From: Wei Xu >>> >>> Most things like ipv4 except there is a significant difference >>> between ipv4 >>> and ipv6, the fragment lenght in ipv4 header includes itself, while >>> it's not >> typo > Thanks. >> >>> included for ipv6, thus means ipv6 can carry a real '65535' payload. >>> >>> Signed-off-by: Wei Xu >>> --- >>> hw/net/virtio-net.c | 147 >>> +++++++++++++++++++++++++++++++++++++++++++++++++--- >>> 1 file changed, 141 insertions(+), 6 deletions(-) >>> >>> diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c >>> index 81e8e71..2d09352 100644 >>> --- a/hw/net/virtio-net.c >>> +++ b/hw/net/virtio-net.c >>> @@ -50,6 +50,10 @@ >>> /* header lenght value in ip header without option */ >>> #define VIRTIO_NET_IP4_HEADER_LENGTH 5 >>> +#define ETH_IP6_HDR_SZ (ETH_HDR_SZ + IP6_HDR_SZ) >>> +#define VIRTIO_NET_IP6_ADDR_SIZE 32 /* ipv6 saddr + daddr */ >>> +#define VIRTIO_NET_MAX_IP6_PAYLOAD VIRTIO_NET_MAX_TCP_PAYLOAD >>> + >>> /* Purge coalesced packets timer interval */ >>> #define VIRTIO_NET_RSC_INTERVAL 300000 >>> @@ -1725,6 +1729,25 @@ static void >>> virtio_net_rsc_extract_unit4(NetRscChain *chain, >>> unit->payload =3D htons(*unit->ip_plen) - ip_hdrlen - >>> unit->tcp_hdrlen; >>> } >>> +static void virtio_net_rsc_extract_unit6(NetRscChain *chain, >>> + const uint8_t *buf, >>> NetRscUnit* unit) >>> +{ >>> + uint16_t hdr_len; >>> + struct ip6_header *ip6; >>> + >>> + hdr_len =3D ((VirtIONet *)(chain->n))->guest_hdr_len; >>> + ip6 =3D (struct ip6_header *)(buf + hdr_len + sizeof(struct >>> eth_header)); >>> + unit->ip =3D ip6; >>> + unit->ip_plen =3D &(ip6->ip6_ctlun.ip6_un1.ip6_un1_plen); >>> + unit->tcp =3D (struct tcp_header *)(((uint8_t *)unit->ip)\ >>> + + sizeof(struct ip6_header))= ; >>> + unit->tcp_hdrlen =3D (htons(unit->tcp->th_offset_flags) & 0xF000= ) >>> >> 10; >>> + >>> + /* There is a difference between payload lenght in ipv4 and v6, >>> + ip header is excluded in ipv6 */ >>> + unit->payload =3D htons(*unit->ip_plen) - unit->tcp_hdrlen; >>> +} >>> + >>> static void virtio_net_rsc_ipv4_checksum(struct ip_header *ip) >>> { >>> uint32_t sum; >>> @@ -1738,7 +1761,9 @@ static size_t >>> virtio_net_rsc_drain_seg(NetRscChain *chain, NetRscSeg *seg) >>> { >>> int ret; >>> - virtio_net_rsc_ipv4_checksum(seg->unit.ip); >>> + if ((chain->proto =3D=3D ETH_P_IP) && seg->is_coalesced) { >>> + virtio_net_rsc_ipv4_checksum(seg->unit.ip); >>> + } >> Why not introduce proto specific checksum function for chain? > Since there are only 2 protocols to be supported, and very limited > extension for this feature, mst suggest to use direct call in v2 patch > to make things simple, and i took it. Have you tried with my suggestion? I think it will actually simplify the current code (at least several lines of codes).