netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@mellanox.co.il>
To: "David Miller" <davem@davemloft.net>
Cc: netdev@vger.kernel.org, openib-general@openib.org,
	linux-kernel@vger.kernel.org, shemminger@osdl.org
Subject: Re: Dropping NETIF_F_SG since no checksum feature.
Date: Wed, 11 Oct 2006 11:05:04 +0200	[thread overview]
Message-ID: <20061011090504.GC2938@mellanox.co.il> (raw)
In-Reply-To: <20061010.191547.83619974.davem@davemloft.net>

Quoting r. David Miller <davem@davemloft.net>:
> Subject: Re: Dropping NETIF_F_SG since no checksum feature.
> 
> From: "Michael S. Tsirkin" <mst@mellanox.co.il>
> Date: Wed, 11 Oct 2006 02:13:38 +0200
> 
> > Maybe I can patch linux to allow SG without checksum?
> > Dave, maybe you could drop a hint or two on whether this is worthwhile
> > and what are the issues that need addressing to make this work?
> > 
> > I imagine it's not just the matter of changing net/core/dev.c :).
> 
> You can't, it's a quality of implementation issue.  We sendfile()
> pages directly out of the filesystem page cache without any
> blocking of modifications to the page contents, and the only way
> that works is if the card computes the checksum for us.
> 
> If we sendfile() a page directly, we must compute a correct checksum
> no matter what the contents.  We can't do this on the cpu before the
> data hits the device because another thread of execution can go in and
> modify the page contents which would invalidate the checksum and thus
> invalidating the packet.  We cannot allow this.
> 
> Blocking modifications is too expensive, so that's not an option
> either.
> 

But copying still works fine, does it not?
Dave, could you clarify this please?

ssize_t tcp_sendpage(struct socket *sock, struct page *page, int offset,
                     size_t size, int flags)
{
        ssize_t res;
        struct sock *sk = sock->sk;

        if (!(sk->sk_route_caps & NETIF_F_SG) ||
            !(sk->sk_route_caps & NETIF_F_ALL_CSUM))
                return sock_no_sendpage(sock, page, offset, size, flags);


So, it seems that if I set NETIF_F_SG but clear NETIF_F_ALL_CSUM,
data will be copied over rather than sent directly.
So why does dev.c have to force set NETIF_F_SG to off then?

-- 
MST

  reply	other threads:[~2006-10-11  9:05 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-09 17:47 Dropping NETIF_F_SG since no checksum feature Michael S. Tsirkin
2006-10-09 16:50 ` Stephen Hemminger
2006-10-10 14:43   ` Michael S. Tsirkin
2006-10-10 17:43     ` Stephen Hemminger
2006-10-11  0:13       ` Michael S. Tsirkin
2006-10-11  0:15         ` Roland Dreier
2006-10-11  0:26           ` Michael S. Tsirkin
2006-10-11  3:33             ` Roland Dreier
2006-10-11  3:36               ` David Miller
2006-10-11  3:42                 ` Roland Dreier
2006-10-11  3:45                   ` David Miller
2006-10-11  3:49                     ` Roland Dreier
2006-10-11  3:50                       ` David Miller
2006-10-11  2:15         ` David Miller
2006-10-11  9:05           ` Michael S. Tsirkin [this message]
2006-10-11  9:09             ` Steven Whitehouse
2006-10-11 15:01               ` Michael S. Tsirkin
2006-10-11 20:11                 ` Steven Whitehouse
2006-10-11 20:52                   ` Michael S. Tsirkin
2006-10-11 20:57                   ` Stephen Hemminger
2006-10-11 21:23                     ` Michael S. Tsirkin
2006-10-11 21:29                       ` Stephen Hemminger
2006-10-11 21:42                         ` Michael S. Tsirkin
2006-10-11 21:41                       ` David Miller
2006-10-12 19:12                         ` Michael S. Tsirkin
2006-10-13  4:22                           ` David Miller
2006-10-13  6:17                             ` Michael S. Tsirkin
2006-10-11 20:52                 ` David Miller
2006-10-11 21:11                   ` Michael S. Tsirkin
2006-10-11  9:20             ` David Miller
2006-10-11  9:46               ` Michael S. Tsirkin
2006-10-11 18:21                 ` [openib-general] " Michael Krause
2006-10-11 13:11               ` [RFC] Question about potential problem in net/ipv4/route.c Eric Dumazet
2006-10-12  5:05                 ` David Miller
2006-10-12  5:31                   ` Patrick McHardy
2006-10-12  5:54                     ` David Miller
2006-10-12  5:48                   ` Eric Dumazet
2006-10-12  6:02                     ` David Miller
2006-10-12  6:10                       ` Patrick McHardy
2006-10-12  6:25                         ` David Miller
2006-10-12  6:35                       ` Eric Dumazet
2006-10-12  7:48                         ` David Miller
2006-10-16  9:00                 ` [PATCH] NET : Suspicious locking in reqsk_queue_hash_req() Eric Dumazet
2006-10-16  9:07                   ` Eric Dumazet
2006-10-16 16:16                     ` Arnaldo Carvalho de Melo
2006-10-16 16:56                       ` Eric Dumazet
2006-10-16 17:39                         ` Eric Dumazet
2006-10-16 20:41                   ` David Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20061011090504.GC2938@mellanox.co.il \
    --to=mst@mellanox.co.il \
    --cc=davem@davemloft.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=openib-general@openib.org \
    --cc=shemminger@osdl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).