-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
2xTx: Refactor to separate Transaction packets from MTU packets #29055
Conversation
dc573ce
to
a9e1065
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks like a great step in the right direction; still working through some pieces / digesting so will take a more thorough pass in tomorrow
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me: despite the size of the changes, 99% of the them are to introduce parametrized types for packets. For the rest, I have only minor comments
&bank_forks, | ||
unprocessed_transaction_storage, | ||
|
||
if i == 0 || i == 1 { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you leave a comment why for 0 and 1 we handle it differently?
Looks like this piece of code requires some refactoring: I think this building logic should be moved to constructor (if it is generic enough) or to some factory function. If you agree, would be nice to leave a comment like TODO(jon): #<issue id> refactor unprocessed_transaction_storage creation in banking stage
and you can assign it to me
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please don't add new TODO
s into the code 🙏🏼
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wanted to keep the changeset as limited as possible while still doing what was needed. I added a point in the project to address this, and I'll put in a comment explaining what's happening.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please don't add new
TODO
s into the code 🙏🏼
sorry, I wrote this before the discussion on discord
Pull request has been modified.
607aa5e
to
f1c2e41
Compare
Rebased onto #29092 |
sdk/src/packet.rs
Outdated
pub trait BasePacket: Default + Clone + Sync + Send + Eq + fmt::Debug { | ||
const DATA_SIZE: usize; | ||
fn populate_packet<T: Serialize>(&mut self, dest: Option<&SocketAddr>, data: &T) -> Result<()>; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the benefit of this trait as opposed to using const generics for packet data size and then defining some typedefs for Packet
and TransactionPacket
?
Something like:
struct GenericPacket<const N: usize> {
buffer: [u8; N],
meta: Meta,
}
type Packet = GenericPacket<PACKET_DATA_SIZE>;
type TransactionPacket = GenericPacket<TRANSACTION_DATA_SIZE>;
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To be honest, I was worried that a second template parameter would make the refactor even longer and more confusing. But it's much better than a macro! Done in ddca0da, thanks for the suggestion!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, now it's actually done, along with the removal of meta()
and meta_mut()
@joncinque hey, fyi, I'm touching |
btw, completely layman's dumb question: why are we so insisting on arrays? is there justifiable perf observation with realistic mainnet-beta load? I think we can just switch to Vec for now, considering the 2xTx project. |
I would not suggest using |
@ryoqun ok great, thanks for the heads up! Since you're planning to backport, it probably makes more sense for you to merge first. It doesn't look the change for me will be too bad, but I guess we'll have to see. |
416817c
to
db2eee1
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks a bit more cumbersome than before but if it since it allows doing static checks, I'm for it
5546317
to
753975d
Compare
Pull request has been modified.
@joncinque - this PR got stale 😭 |
@mvines we're still not sure if this is the right approach, and need to do some testing on it to see. Thanks for flagging that it went stale! |
753975d
to
41653fe
Compare
sonofa |
Merge conflicts on this were monstrous, so I ended up squashing everything and retrying from there. I've almost got a branch ready, which I'll put up in a new PR |
Problem
As we march towards larger transaction sizes, we want to avoid having a negative impact on the rest of the networking layer. Currently, everything is treated as a general
PacketBatch
, which is always assumed to have the same size.For transactions, packets may be larger than 1 MTU, so we need a way to separate transaction packets from all other packets.
Summary of Changes
This is entirely a (pretty big) refactor to make
PacketBatch
into a generic struct that can accept either aPacket
or aTransactionPacket
, through aBasePacket
trait.In this PR, both packet types have the same size, so this PR can be merged. Here's what it does in total
BasePacket
trait, implemented byPacket
andTransactionPacket
PacketBatch
toBatch<P: BasePacket>
, use everywhereTransactionPacket
for transactions in RPC, banking stage, fetch stage, sigverify, and QUICAdditional changes required to the refactor:
SigVerifier
trait, which only had one other totally unused implementation. This made the templating much less messy*const Packet
, while the underlying libs takeuint8_t*
, so updated that to*const u8
. This worked fine in testing.Packet
s and one forTransactionPacket
s. I used the same values to create both of them, but that can be tweaked if neededTransactionSigVerifier
s, one forTransactionPacket
(normal tx processing) and one forPacket
(vote processing). No change to functionality, just might be confusingThe only potential impact to performance would be going through the trait to get the
meta()
andmeta_mut()
, but those should get inlined by the compiler since there's no dynamic dispatch, only templating.For testing, we can add a simple patch to this that doubles
TransactionPacket
's size.For future work, the idea is to update
TransactionPacket
to have variable size.Fixes #