All of lore.kernel.org
 help / color / mirror / Atom feed
From: Casey Schaufler <casey@schaufler-ca.com>
To: David Miller <davem@davemloft.net>
Cc: pmoore@redhat.com, eric.dumazet@gmail.com,
	netdev@vger.kernel.org, mvadkert@redhat.com,
	selinux@tycho.nsa.gov, linux-security-module@vger.kernel.org,
	Casey Schaufler <casey@schaufler-ca.com>
Subject: Re: [PATCH] tcp: assign the sock correctly to an outgoing SYNACK packet
Date: Mon, 08 Apr 2013 16:40:35 -0700	[thread overview]
Message-ID: <51635573.7030706@schaufler-ca.com> (raw)
In-Reply-To: <20130408.173325.1683493727549657170.davem@davemloft.net>

On 4/8/2013 2:33 PM, David Miller wrote:
> From: Paul Moore <pmoore@redhat.com>
> Date: Mon, 08 Apr 2013 17:24:50 -0400
>
>> If the void pointer is wrapped by a #ifdef (plenty of precedence for that) and 
>> the management of that pointer is handled by LSM hooks why is it a concern?  I 
>> apologize for pushing on the issue, but I'm having a hard time reconciling the 
>> reason for the "no" with the comments/decisions about the regression fix; at 
>> present there seems to be a level of contradiction between the two.
> 8 bytes times however many millions of packets per second we can process
> on a big machine, you do the math.

OK, let's do the math.

First off, it's 4 bytes, not 8. It replaces the secmark.
Your increased memory usage is going to be

	4 bytes/packet *  M packets/second * N seconds

Where M is the rate at which you're processing packets and
N is the length of time it takes to process a packet.

Let's pretend we have an embedded system that does nothing but send
128 byte packets on a 10Gb port. That's 10M packets/second. If it
takes a full second to process a packet the overhead is 40MB for that
second. I have it on good authority that packets can be processed
in considerably less time than that. The real number is more like
0.05 seconds. That means your actual overhead is more like 1MB.

These are dumbed down calculations. I am not a memory usage expert.
I am convinced that "real" calculations are going to get similar
numbers. I am, of course, willing to be swayed by evidence that I
am wrong.

Compare that to the overhead associated with using CIPSO on packets
that never leave the box.



>
> It's memory, less cache locality, etc. etc. etc.
>
> It's the most important data structure in the entire networking stack,
> and every single byte matters.
>
> I want the overhead to be your problem, so that only users of your
> stuff eat the overhead, rather than everyone.
>
> And don't even mention ifdefs, that's bogus, because every
> distribution turns every option on, %99.9999999 of users will
> therefore not see the savings.
>
> Really, this is a dead topic, let's move on.
>
> Thanks.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

WARNING: multiple messages have this Message-ID (diff)
From: Casey Schaufler <casey@schaufler-ca.com>
To: David Miller <davem@davemloft.net>
Cc: pmoore@redhat.com, eric.dumazet@gmail.com,
	netdev@vger.kernel.org, mvadkert@redhat.com,
	selinux@tycho.nsa.gov, linux-security-module@vger.kernel.org,
	Casey Schaufler <casey@schaufler-ca.com>
Subject: Re: [PATCH] tcp: assign the sock correctly to an outgoing SYNACK packet
Date: Mon, 08 Apr 2013 16:40:35 -0700	[thread overview]
Message-ID: <51635573.7030706@schaufler-ca.com> (raw)
In-Reply-To: <20130408.173325.1683493727549657170.davem@davemloft.net>

On 4/8/2013 2:33 PM, David Miller wrote:
> From: Paul Moore <pmoore@redhat.com>
> Date: Mon, 08 Apr 2013 17:24:50 -0400
>
>> If the void pointer is wrapped by a #ifdef (plenty of precedence for that) and 
>> the management of that pointer is handled by LSM hooks why is it a concern?  I 
>> apologize for pushing on the issue, but I'm having a hard time reconciling the 
>> reason for the "no" with the comments/decisions about the regression fix; at 
>> present there seems to be a level of contradiction between the two.
> 8 bytes times however many millions of packets per second we can process
> on a big machine, you do the math.

OK, let's do the math.

First off, it's 4 bytes, not 8. It replaces the secmark.
Your increased memory usage is going to be

	4 bytes/packet *  M packets/second * N seconds

Where M is the rate at which you're processing packets and
N is the length of time it takes to process a packet.

Let's pretend we have an embedded system that does nothing but send
128 byte packets on a 10Gb port. That's 10M packets/second. If it
takes a full second to process a packet the overhead is 40MB for that
second. I have it on good authority that packets can be processed
in considerably less time than that. The real number is more like
0.05 seconds. That means your actual overhead is more like 1MB.

These are dumbed down calculations. I am not a memory usage expert.
I am convinced that "real" calculations are going to get similar
numbers. I am, of course, willing to be swayed by evidence that I
am wrong.

Compare that to the overhead associated with using CIPSO on packets
that never leave the box.



>
> It's memory, less cache locality, etc. etc. etc.
>
> It's the most important data structure in the entire networking stack,
> and every single byte matters.
>
> I want the overhead to be your problem, so that only users of your
> stuff eat the overhead, rather than everyone.
>
> And don't even mention ifdefs, that's bogus, because every
> distribution turns every option on, %99.9999999 of users will
> therefore not see the savings.
>
> Really, this is a dead topic, let's move on.
>
> Thanks.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


  parent reply	other threads:[~2013-04-08 23:40 UTC|newest]

Thread overview: 81+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-08 15:45 [PATCH] tcp: assign the sock correctly to an outgoing SYNACK packet Paul Moore
2013-04-08 16:14 ` David Miller
2013-04-08 17:22   ` Paul Moore
2013-04-08 17:36     ` Eric Dumazet
2013-04-08 17:40       ` Paul Moore
2013-04-08 17:47         ` Eric Dumazet
2013-04-08 18:01           ` Eric Dumazet
2013-04-08 18:12           ` Paul Moore
2013-04-08 18:21             ` Eric Dumazet
2013-04-08 18:26               ` Paul Moore
2013-04-08 18:34                 ` Eric Dumazet
2013-04-08 18:30               ` Eric Dumazet
2013-04-08 20:37                 ` Paul Moore
2013-04-08 20:44                   ` David Miller
2013-04-08 20:53                     ` Paul Moore
2013-04-08 20:55                   ` Eric Dumazet
2013-04-08 21:09                     ` Paul Moore
2013-04-08 21:14                       ` David Miller
2013-04-08 21:17                       ` Eric Dumazet
2013-04-09  3:58                       ` [PATCH] selinux: add a skb_owned_by() hook Eric Dumazet
2013-04-09  4:29                         ` Casey Schaufler
2013-04-09  4:41                           ` David Miller
2013-04-09  5:14                             ` Casey Schaufler
2013-04-09 11:39                             ` Paul Moore
2013-04-09  6:24                           ` Eric Dumazet
2013-04-09 11:45                           ` Paul Moore
2013-04-09  7:38                         ` James Morris
2013-04-09 12:06                         ` Paul Moore
2013-04-09 17:23                         ` David Miller
2013-04-08 18:32             ` [PATCH] tcp: assign the sock correctly to an outgoing SYNACK packet Paul Moore
2013-04-08 18:32               ` Paul Moore
2013-04-08 21:10               ` Paul Moore
2013-04-08 21:10                 ` Paul Moore
2013-04-08 21:15                 ` David Miller
2013-04-08 21:24                   ` Paul Moore
2013-04-08 21:24                     ` Paul Moore
2013-04-08 21:33                     ` David Miller
2013-04-08 22:01                       ` Paul Moore
2013-04-08 22:01                         ` Paul Moore
2013-04-08 22:08                         ` David Miller
2013-04-08 23:40                       ` Casey Schaufler [this message]
2013-04-08 23:40                         ` Casey Schaufler
2013-04-09  0:33                         ` Eric Dumazet
2013-04-09  0:59                           ` Casey Schaufler
2013-04-09  0:59                             ` Casey Schaufler
2013-04-09  1:09                             ` Eric Dumazet
2013-04-09  1:24                               ` Casey Schaufler
2013-04-09  1:24                                 ` Casey Schaufler
2013-04-09 13:19                                 ` Paul Moore
2013-04-09 13:19                                   ` Paul Moore
2013-04-09 13:33                                   ` Paul Moore
2013-04-09 13:33                                     ` Paul Moore
2013-04-09 14:00                                   ` Eric Dumazet
2013-04-09 14:19                                     ` Paul Moore
2013-04-09 14:19                                       ` Paul Moore
2013-04-09 14:31                                       ` Eric Dumazet
2013-04-09 14:52                                         ` Paul Moore
2013-04-09 14:52                                           ` Paul Moore
2013-04-09 15:05                                           ` Paul Moore
2013-04-09 15:05                                             ` Paul Moore
2013-04-09 15:07                                           ` Eric Dumazet
2013-04-09 15:17                                             ` Paul Moore
2013-04-09 15:17                                               ` Paul Moore
2013-04-09 15:32                                               ` Eric Dumazet
2013-04-09 15:57                                                 ` Paul Moore
2013-04-09 15:57                                                   ` Paul Moore
2013-04-09 16:11                                                 ` Casey Schaufler
2013-04-09 16:11                                                   ` Casey Schaufler
2013-04-09 16:56                                                 ` David Miller
2013-04-09 17:00                                                   ` Paul Moore
2013-04-09 17:00                                                     ` Paul Moore
2013-04-09 17:09                                                     ` David Miller
2013-04-09 17:10                                                       ` David Miller
2013-04-09 14:05                                   ` Ben Hutchings
2013-04-09 14:10                                     ` Paul Moore
2013-04-09 14:10                                       ` Paul Moore
2013-04-08 21:34                     ` Ben Hutchings
2013-04-08 19:25     ` David Miller
2013-04-08 16:19 ` Eric Dumazet
2013-04-08 18:03 ` Sergei Shtylyov
2013-04-08 18:12   ` Paul Moore

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=51635573.7030706@schaufler-ca.com \
    --to=casey@schaufler-ca.com \
    --cc=davem@davemloft.net \
    --cc=eric.dumazet@gmail.com \
    --cc=linux-security-module@vger.kernel.org \
    --cc=mvadkert@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=pmoore@redhat.com \
    --cc=selinux@tycho.nsa.gov \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.