This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/gerrit-log@lists.osmocom.org/.
laforge gerrit-no-reply at lists.osmocom.orglaforge has posted comments on this change. ( https://gerrit.osmocom.org/c/libosmocore/+/22343 ) Change subject: gprs_ns2: inform the NS user (BSSGP) about the MTU of a NSE ...................................................................... Patch Set 2: Code-Review-1 (3 comments) https://gerrit.osmocom.org/c/libosmocore/+/22343/2/src/gb/gprs_ns2_frgre.c File src/gb/gprs_ns2_frgre.c: https://gerrit.osmocom.org/c/libosmocore/+/22343/2/src/gb/gprs_ns2_frgre.c@572 PS2, Line 572: 1500 I think this changes from current behavior. I think the old code would simply IP-fragment, which is actually intended in that situation. What matters here is not the MTU of the Ethernet device, but what kind of UDP packet payload size we can transmit. https://gerrit.osmocom.org/c/libosmocore/+/22343/2/src/gb/gprs_ns2_internal.h File src/gb/gprs_ns2_internal.h: https://gerrit.osmocom.org/c/libosmocore/+/22343/2/src/gb/gprs_ns2_internal.h@240 PS2, Line 240: is there a reason to use a signed value? like negative having a special meaning? If yes, please docuemnt in comment, if not I'd suggest unsigned int. https://gerrit.osmocom.org/c/libosmocore/+/22343/2/src/gb/gprs_ns2_udp.c File src/gb/gprs_ns2_udp.c: https://gerrit.osmocom.org/c/libosmocore/+/22343/2/src/gb/gprs_ns2_udp.c@121 PS2, Line 121: int also here I'm not sure if we really should worry about the MTU of the ethernet. In the end, we have potentially larger BSSGP frames and there is no way to influence the size of the upper layer frames. Think of a PDP context with MTU 1500 (or close to that), plus the LLC, SNDCP, BSSGP overhead -> boom. Yes, we may end up generating IP fragments. But then, the bandwidth of GPRS is ultra low, so what do we care about some more packets in the core network over wired interfaces that likely have more than a thousand time more bandwidth than our radio interface. If we enforce staying within the MTU of the ethernet device, we would start dropping packets with no way to inform this up the protocol stack so that the LLC/SNDCP XID exchange could negotiate smaller packet sizes. - i.e. we'd effectively break the network completely. I think the only situation wherer the MTU matters is in the case of FR, where we have a fixed, well-known MTU and no support from the transport (FR) to do segmentation / fragmentation by itself. Luckily it's 1600, and hence we do have some room for BSSGP/LLC/SNDCP overhead -- To view, visit https://gerrit.osmocom.org/c/libosmocore/+/22343 To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: libosmocore Gerrit-Branch: master Gerrit-Change-Id: I5016b295db6185ec131d83089cf6c806e34ef1b6 Gerrit-Change-Number: 22343 Gerrit-PatchSet: 2 Gerrit-Owner: lynxis lazus <lynxis at fe80.eu> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: daniel <dwillmann at sysmocom.de> Gerrit-Reviewer: laforge <laforge at osmocom.org> Gerrit-Comment-Date: Wed, 20 Jan 2021 22:02:36 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: Yes Gerrit-MessageType: comment -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20210120/36b87bcb/attachment.htm>