Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Large transport bufs #806

Merged
merged 2 commits into from
Jul 9, 2020
Merged

Conversation

agrover
Copy link
Contributor

@agrover agrover commented Jul 8, 2020

Increase transport send & recv bufs from 64K to 1M. Most of this PR is updating tests in http3 and transport to not depend on buffers being a certain size.

@agrover agrover requested review from martinthomson and ddragana July 8, 2020 21:50
@agrover agrover force-pushed the large-transport-bufs branch 3 times, most recently from 6fbbe53 to 07384bd Compare July 8, 2020 23:13
Copy link
Member

@martinthomson martinthomson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would a smaller buffer for test configurations help the tests run faster? Or is 1M still small enough we won't notice?

@@ -1852,7 +1852,7 @@ mod tests {
if let ConnectionEvent::RecvStreamReadable { stream_id } = e {
if stream_id == request_stream_id {
// Read the DATA frame.
let mut buf = [1_u8; 0xffff];
let mut buf = vec![1_u8; Connection::stream_recv_buffer_size()];
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this an associated function and not an exported constant?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think exported constant is better. I'll follow up with another PR.

@@ -280,7 +280,7 @@ pub struct TxBuffer {
}

impl TxBuffer {
const BUFFER_SIZE: usize = 0xFFFF; // 64 KiB
pub const BUFFER_SIZE: usize = 0x10_0000; // 1 MiB
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you think that it makes sense to use a single common constant for these?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think keeping them separate might come in handy, so let's keep them separate for now.

Andy Grover added 2 commits July 9, 2020 00:46
This should help to prevent STREAM_DATA_BLOCKED messages.

Fix up max_data() test that broke when const was increased. Also expose
TxBuffer::BUFFER_SIZE to avoid raw numbers as much as possible.
Add static const methods to get send and receive buffer sizes. This is
useful for testing in http3 crate, for example.

Alter tests in http3 and transport crates to not assume a given buffer
size.
@agrover agrover force-pushed the large-transport-bufs branch from 07384bd to b6f89b1 Compare July 9, 2020 00:47
@mergify mergify bot merged commit 93a5d0a into mozilla:master Jul 9, 2020
@agrover agrover deleted the large-transport-bufs branch July 10, 2020 17:12
agrover pushed a commit to agrover/neqo that referenced this pull request Jul 10, 2020
Followup to mozilla#806, this is simpler than const methods on Connection.

Note that while we can change these constants now, setting them to
different values will cause some tests to fail. Spending time to fix
tests for different const values is not justified yet.
agrover pushed a commit to agrover/neqo that referenced this pull request Jul 10, 2020
Followup to mozilla#806, this is simpler than const methods on Connection.

Note that while we can change these constants now, setting them to
different values will cause some tests to fail. Spending time to fix
tests for different const values is not justified yet.
agrover pushed a commit to agrover/neqo that referenced this pull request Jul 10, 2020
Followup to mozilla#806, this is simpler than const methods on Connection.

Note that while we can change these constants now, setting them to
different values will cause some tests to fail. Spending time to fix
tests for different const values is not justified yet.
mergify bot pushed a commit that referenced this pull request Jul 13, 2020
Followup to #806, this is simpler than const methods on Connection.

Note that while we can change these constants now, setting them to
different values will cause some tests to fail. Spending time to fix
tests for different const values is not justified yet.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants