I'd group the changes by "topic", or kind of change. (It's a bit hard to say in the abstract, without having seen the changes.)
E.g. I guess you'll add a new src/base/platform/, that could be its own CL. More generally:
- any reasonably self-contained thing/concept that you're adding can be its own CL.
- if you're making the same type of mechanical change (renaming, adding #includes, ...) across the codebase, one such change (or a group of tightly coupled / very similar changes) can be its own CL.
- if those criteria aren't enough to get to manageable CL sizes, split by paths (e.g. src/base/, src/*, test/cctests/, test/unittests/, ...). For the definition of "manageable", ask yourself what you'd like to review. As a rough guideline, if it's more than 500 lines or more than 20 files at once, I'd ask whether that's really the smallest unit that makes sense. (Sometimes it is!)