You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafficserver.apache.org by "Leif Hedstrom (JIRA)" <ji...@apache.org> on 2011/05/21 00:00:48 UTC
[jira] [Created] (TS-795) Clean up definitions and usage of buffer
size indexes vs buffer sizes
Clean up definitions and usage of buffer size indexes vs buffer sizes
---------------------------------------------------------------------
Key: TS-795
URL: https://issues.apache.org/jira/browse/TS-795
Project: Traffic Server
Issue Type: Improvement
Components: Core
Reporter: Leif Hedstrom
Fix For: 3.1
Right now, we have a set of defines, and APIs, which can take either a "index" to a size (used e.g. for an allocator index), or a real size. Both of these are currently int64_t in all APIs and member variables, and in the implementations, the usage are sometimes overloaded (i.e. we do "size" calculations on top of the indexes, making for real confusing code).
There's also a lack of proper identification of what is an "size index" type (or parameter), and what is a "size". This makes for risky code.
I think we should clean up all the implementations and APIs, as follow
1) Make proper names of all APIs and macros, clearly indicating if it's working on a size index or a size.
2) Keep only the size types, parameters and macros using int64_t. Do not overload "real" size over the size indexes.
3) We either make the size indexes an "int" (or even a short), or perhaps even better an enum (like below). All APIs, parameters, and member variables that refer to such size indexes would use this appropriate type.
{code}
enum BufferSizeIndex {
BUFFER_SIZE_INDEX_128 = 0,
BUFFER_SIZE_INDEX_256, /* 1 */
BUFFER_SIZE_INDEX_512, /* 2 */
BUFFER_SIZE_INDEX_1K, /* 3 */
BUFFER_SIZE_INDEX_2K, /* 4 */
BUFFER_SIZE_INDEX_4K, /* 5 */
BUFFER_SIZE_INDEX_8K, /* 6 */
BUFFER_SIZE_INDEX_16K, /* 7 */
BUFFER_SIZE_INDEX_32K, /* 8 */
BUFFER_SIZE_INDEX_64K, /* 9 */
BUFFER_SIZE_INDEX_128K, /* 10 */
BUFFER_SIZE_INDEX_256K, /* 11 */
BUFFER_SIZE_INDEX_512K, /* 12 */
BUFFER_SIZE_INDEX_1M, /* 13 */
BUFFER_SIZE_INDEX_2M, /* 14 */
/* These have special semantics */
BUFFER_SIZE_NOT_ALLOCATED,
};
{CODE}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-795) Clean up definitions and usage of
buffer size indexes vs buffer sizes
Posted by "Leif Hedstrom (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TS-795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13040659#comment-13040659 ]
Leif Hedstrom commented on TS-795:
----------------------------------
It's probably questionable too if all these buffer sizes needs to be int64_t as well. I'm not 100% certain why that was done, but cleanup here is in order.
> Clean up definitions and usage of buffer size indexes vs buffer sizes
> ---------------------------------------------------------------------
>
> Key: TS-795
> URL: https://issues.apache.org/jira/browse/TS-795
> Project: Traffic Server
> Issue Type: Improvement
> Components: Core
> Reporter: Leif Hedstrom
> Fix For: 3.1.0
>
>
> Right now, we have a set of defines, and APIs, which can take either a "index" to a size (used e.g. for an allocator index), or a real size. Both of these are currently int64_t in all APIs and member variables, and in the implementations, the usage are sometimes overloaded (i.e. we do "size" calculations on top of the indexes, making for real confusing code).
> There's also a lack of proper identification of what is an "size index" type (or parameter), and what is a "size". This makes for risky code.
> I think we should clean up all the implementations and APIs, as follow
> 1) Make proper names of all APIs and macros, clearly indicating if it's working on a size index or a size.
> 2) Keep only the size types, parameters and macros using int64_t. Do not overload "real" size over the size indexes.
> 3) We either make the size indexes an "int" (or even a short), or perhaps even better an enum (like below). All APIs, parameters, and member variables that refer to such size indexes would use this appropriate type.
> {code}
> enum BufferSizeIndex {
> BUFFER_SIZE_INDEX_128 = 0,
> BUFFER_SIZE_INDEX_256, /* 1 */
> BUFFER_SIZE_INDEX_512, /* 2 */
> BUFFER_SIZE_INDEX_1K, /* 3 */
> BUFFER_SIZE_INDEX_2K, /* 4 */
> BUFFER_SIZE_INDEX_4K, /* 5 */
> BUFFER_SIZE_INDEX_8K, /* 6 */
> BUFFER_SIZE_INDEX_16K, /* 7 */
> BUFFER_SIZE_INDEX_32K, /* 8 */
> BUFFER_SIZE_INDEX_64K, /* 9 */
> BUFFER_SIZE_INDEX_128K, /* 10 */
> BUFFER_SIZE_INDEX_256K, /* 11 */
> BUFFER_SIZE_INDEX_512K, /* 12 */
> BUFFER_SIZE_INDEX_1M, /* 13 */
> BUFFER_SIZE_INDEX_2M, /* 14 */
> /* These have special semantics */
> BUFFER_SIZE_NOT_ALLOCATED,
> };
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-795) Clean up definitions and usage of buffer
size indexes vs buffer sizes
Posted by "Leif Hedstrom (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TS-795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Leif Hedstrom updated TS-795:
-----------------------------
Fix Version/s: (was: 3.1.2)
3.2.0
> Clean up definitions and usage of buffer size indexes vs buffer sizes
> ---------------------------------------------------------------------
>
> Key: TS-795
> URL: https://issues.apache.org/jira/browse/TS-795
> Project: Traffic Server
> Issue Type: Improvement
> Components: Core
> Reporter: Leif Hedstrom
> Fix For: 3.2.0
>
>
> Right now, we have a set of defines, and APIs, which can take either a "index" to a size (used e.g. for an allocator index), or a real size. Both of these are currently int64_t in all APIs and member variables, and in the implementations, the usage are sometimes overloaded (i.e. we do "size" calculations on top of the indexes, making for real confusing code).
> There's also a lack of proper identification of what is an "size index" type (or parameter), and what is a "size". This makes for risky code.
> I think we should clean up all the implementations and APIs, as follow
> 1) Make proper names of all APIs and macros, clearly indicating if it's working on a size index or a size.
> 2) Keep only the size types, parameters and macros using int64_t. Do not overload "real" size over the size indexes.
> 3) We either make the size indexes an "int" (or even a short), or perhaps even better an enum (like below). All APIs, parameters, and member variables that refer to such size indexes would use this appropriate type.
> {code}
> enum BufferSizeIndex {
> BUFFER_SIZE_INDEX_128 = 0,
> BUFFER_SIZE_INDEX_256, /* 1 */
> BUFFER_SIZE_INDEX_512, /* 2 */
> BUFFER_SIZE_INDEX_1K, /* 3 */
> BUFFER_SIZE_INDEX_2K, /* 4 */
> BUFFER_SIZE_INDEX_4K, /* 5 */
> BUFFER_SIZE_INDEX_8K, /* 6 */
> BUFFER_SIZE_INDEX_16K, /* 7 */
> BUFFER_SIZE_INDEX_32K, /* 8 */
> BUFFER_SIZE_INDEX_64K, /* 9 */
> BUFFER_SIZE_INDEX_128K, /* 10 */
> BUFFER_SIZE_INDEX_256K, /* 11 */
> BUFFER_SIZE_INDEX_512K, /* 12 */
> BUFFER_SIZE_INDEX_1M, /* 13 */
> BUFFER_SIZE_INDEX_2M, /* 14 */
> /* These have special semantics */
> BUFFER_SIZE_NOT_ALLOCATED,
> };
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-795) Clean up definitions and usage of buffer
size indexes vs buffer sizes
Posted by "Leif Hedstrom (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TS-795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Leif Hedstrom updated TS-795:
-----------------------------
Description:
Right now, we have a set of defines, and APIs, which can take either a "index" to a size (used e.g. for an allocator index), or a real size. Both of these are currently int64_t in all APIs and member variables, and in the implementations, the usage are sometimes overloaded (i.e. we do "size" calculations on top of the indexes, making for real confusing code).
There's also a lack of proper identification of what is an "size index" type (or parameter), and what is a "size". This makes for risky code.
I think we should clean up all the implementations and APIs, as follow
1) Make proper names of all APIs and macros, clearly indicating if it's working on a size index or a size.
2) Keep only the size types, parameters and macros using int64_t. Do not overload "real" size over the size indexes.
3) We either make the size indexes an "int" (or even a short), or perhaps even better an enum (like below). All APIs, parameters, and member variables that refer to such size indexes would use this appropriate type.
{code}
enum BufferSizeIndex {
BUFFER_SIZE_INDEX_128 = 0,
BUFFER_SIZE_INDEX_256, /* 1 */
BUFFER_SIZE_INDEX_512, /* 2 */
BUFFER_SIZE_INDEX_1K, /* 3 */
BUFFER_SIZE_INDEX_2K, /* 4 */
BUFFER_SIZE_INDEX_4K, /* 5 */
BUFFER_SIZE_INDEX_8K, /* 6 */
BUFFER_SIZE_INDEX_16K, /* 7 */
BUFFER_SIZE_INDEX_32K, /* 8 */
BUFFER_SIZE_INDEX_64K, /* 9 */
BUFFER_SIZE_INDEX_128K, /* 10 */
BUFFER_SIZE_INDEX_256K, /* 11 */
BUFFER_SIZE_INDEX_512K, /* 12 */
BUFFER_SIZE_INDEX_1M, /* 13 */
BUFFER_SIZE_INDEX_2M, /* 14 */
/* These have special semantics */
BUFFER_SIZE_NOT_ALLOCATED,
};
{code}
was:
Right now, we have a set of defines, and APIs, which can take either a "index" to a size (used e.g. for an allocator index), or a real size. Both of these are currently int64_t in all APIs and member variables, and in the implementations, the usage are sometimes overloaded (i.e. we do "size" calculations on top of the indexes, making for real confusing code).
There's also a lack of proper identification of what is an "size index" type (or parameter), and what is a "size". This makes for risky code.
I think we should clean up all the implementations and APIs, as follow
1) Make proper names of all APIs and macros, clearly indicating if it's working on a size index or a size.
2) Keep only the size types, parameters and macros using int64_t. Do not overload "real" size over the size indexes.
3) We either make the size indexes an "int" (or even a short), or perhaps even better an enum (like below). All APIs, parameters, and member variables that refer to such size indexes would use this appropriate type.
{code}
enum BufferSizeIndex {
BUFFER_SIZE_INDEX_128 = 0,
BUFFER_SIZE_INDEX_256, /* 1 */
BUFFER_SIZE_INDEX_512, /* 2 */
BUFFER_SIZE_INDEX_1K, /* 3 */
BUFFER_SIZE_INDEX_2K, /* 4 */
BUFFER_SIZE_INDEX_4K, /* 5 */
BUFFER_SIZE_INDEX_8K, /* 6 */
BUFFER_SIZE_INDEX_16K, /* 7 */
BUFFER_SIZE_INDEX_32K, /* 8 */
BUFFER_SIZE_INDEX_64K, /* 9 */
BUFFER_SIZE_INDEX_128K, /* 10 */
BUFFER_SIZE_INDEX_256K, /* 11 */
BUFFER_SIZE_INDEX_512K, /* 12 */
BUFFER_SIZE_INDEX_1M, /* 13 */
BUFFER_SIZE_INDEX_2M, /* 14 */
/* These have special semantics */
BUFFER_SIZE_NOT_ALLOCATED,
};
{CODE}
> Clean up definitions and usage of buffer size indexes vs buffer sizes
> ---------------------------------------------------------------------
>
> Key: TS-795
> URL: https://issues.apache.org/jira/browse/TS-795
> Project: Traffic Server
> Issue Type: Improvement
> Components: Core
> Reporter: Leif Hedstrom
> Fix For: 3.1
>
>
> Right now, we have a set of defines, and APIs, which can take either a "index" to a size (used e.g. for an allocator index), or a real size. Both of these are currently int64_t in all APIs and member variables, and in the implementations, the usage are sometimes overloaded (i.e. we do "size" calculations on top of the indexes, making for real confusing code).
> There's also a lack of proper identification of what is an "size index" type (or parameter), and what is a "size". This makes for risky code.
> I think we should clean up all the implementations and APIs, as follow
> 1) Make proper names of all APIs and macros, clearly indicating if it's working on a size index or a size.
> 2) Keep only the size types, parameters and macros using int64_t. Do not overload "real" size over the size indexes.
> 3) We either make the size indexes an "int" (or even a short), or perhaps even better an enum (like below). All APIs, parameters, and member variables that refer to such size indexes would use this appropriate type.
> {code}
> enum BufferSizeIndex {
> BUFFER_SIZE_INDEX_128 = 0,
> BUFFER_SIZE_INDEX_256, /* 1 */
> BUFFER_SIZE_INDEX_512, /* 2 */
> BUFFER_SIZE_INDEX_1K, /* 3 */
> BUFFER_SIZE_INDEX_2K, /* 4 */
> BUFFER_SIZE_INDEX_4K, /* 5 */
> BUFFER_SIZE_INDEX_8K, /* 6 */
> BUFFER_SIZE_INDEX_16K, /* 7 */
> BUFFER_SIZE_INDEX_32K, /* 8 */
> BUFFER_SIZE_INDEX_64K, /* 9 */
> BUFFER_SIZE_INDEX_128K, /* 10 */
> BUFFER_SIZE_INDEX_256K, /* 11 */
> BUFFER_SIZE_INDEX_512K, /* 12 */
> BUFFER_SIZE_INDEX_1M, /* 13 */
> BUFFER_SIZE_INDEX_2M, /* 14 */
> /* These have special semantics */
> BUFFER_SIZE_NOT_ALLOCATED,
> };
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-795) Clean up definitions and usage of
buffer size indexes vs buffer sizes
Posted by "Leif Hedstrom (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TS-795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13454981#comment-13454981 ]
Leif Hedstrom commented on TS-795:
----------------------------------
I should also point out that even though we have e.g. proxy.config.http.default_buffer_size (defaults to 8 == 32KB), we don't consistently use this. Some places, such as the HttpFetchSM hardcodes it to 32KB if I recall, and I think a few other places does as well.
> Clean up definitions and usage of buffer size indexes vs buffer sizes
> ---------------------------------------------------------------------
>
> Key: TS-795
> URL: https://issues.apache.org/jira/browse/TS-795
> Project: Traffic Server
> Issue Type: Improvement
> Components: Core
> Reporter: Leif Hedstrom
> Fix For: 3.3.1
>
>
> Right now, we have a set of defines, and APIs, which can take either a "index" to a size (used e.g. for an allocator index), or a real size. Both of these are currently int64_t in all APIs and member variables, and in the implementations, the usage are sometimes overloaded (i.e. we do "size" calculations on top of the indexes, making for real confusing code).
> There's also a lack of proper identification of what is an "size index" type (or parameter), and what is a "size". This makes for risky code.
> I think we should clean up all the implementations and APIs, as follow
> 1) Make proper names of all APIs and macros, clearly indicating if it's working on a size index or a size.
> 2) Keep only the size types, parameters and macros using int64_t. Do not overload "real" size over the size indexes.
> 3) We either make the size indexes an "int" (or even a short), or perhaps even better an enum (like below). All APIs, parameters, and member variables that refer to such size indexes would use this appropriate type.
> {code}
> enum BufferSizeIndex {
> BUFFER_SIZE_INDEX_128 = 0,
> BUFFER_SIZE_INDEX_256, /* 1 */
> BUFFER_SIZE_INDEX_512, /* 2 */
> BUFFER_SIZE_INDEX_1K, /* 3 */
> BUFFER_SIZE_INDEX_2K, /* 4 */
> BUFFER_SIZE_INDEX_4K, /* 5 */
> BUFFER_SIZE_INDEX_8K, /* 6 */
> BUFFER_SIZE_INDEX_16K, /* 7 */
> BUFFER_SIZE_INDEX_32K, /* 8 */
> BUFFER_SIZE_INDEX_64K, /* 9 */
> BUFFER_SIZE_INDEX_128K, /* 10 */
> BUFFER_SIZE_INDEX_256K, /* 11 */
> BUFFER_SIZE_INDEX_512K, /* 12 */
> BUFFER_SIZE_INDEX_1M, /* 13 */
> BUFFER_SIZE_INDEX_2M, /* 14 */
> /* These have special semantics */
> BUFFER_SIZE_NOT_ALLOCATED,
> };
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira