Calculate Your Buffering and Processing Power Needs First.
The RV-C bus operates at 250 Kbps, which translates to a maximum of about 2500 messages per second. In practice you'll rarely see a RV-C bus loaded to more than a tenth of that level. But when you are designing your node you have to presume the worst.
That's because even if only 250 messages are coming each second, they will come in bursts. Most messages are broadcast either in response to an internal timer or in response to a broadcast request. For example, an inverter/charger has about ten messages that it may send when it's 500ms timer triggers. These will likely be sent in rapid succession. If a service tool makes a global request for a DM1, every node in the network will respond immediately, leading to a burst of perhaps a dozen messages. That's the nature of RV-C traffic - burst of data followed by long (relatively speaking) interludes of quiet.
Therefore you have to design your node with the worst-case scenario in mind - one message every 400 microseconds. If your CAN controller has a two-message buffer, you have to be able to service that controller at least every 800 microseconds. A larger buffer reduces the speed you need.
If you plan on parsing your incoming messages immediately, then you must be careful to ensure that the longest path through your parsing routine doesn't exceed the 400 microsecond limit. And that calculation has to consider the possibility of higher-level interrupts or tasks interrupting the routine.
But since your controller probably has other tasks to handle on a tight schedule, the common technique is to set up a secondary buffer that can hold more messages. An ISR merely moves messages from the controller to this secondary buffer, and then the main loop processes the messages in the buffer at its leisure. Now you have milliseconds, not microseconds, to deal with the secondary buffer.